I have a perfectly working Spring Security web application that uses SAML SSO. The client (IdP) changed their certs. I updated the cert and the CA certs to my keystore.jks. I am getting redirected properly to the IdP, I log in and get properly redirected back to my app. At that point I am getting theses in the logs:
Attempting to validate signature using key from supplied credential (validate) (SignatureValidator.java:54)
Creating XMLSignature object (buildSignature) (SignatureValidator.java:90)
Validating signature with signature algorithm URI: http://www.w3.org/2000/09/xmldsig#rsa-sha1 (validate) (SignatureValidator.java:64)
Validation credential key algorithm 'RSA', key instance class 'sun.security.rsa.RSAPublicKeyImpl' (validate) (SignatureValidator.java:65)
Signature validated with key from supplied credential (validate) (SignatureValidator.java:70)
SSL negotiation with xxxxxx using candidate credential was successful (verifySignature) (BaseSignatureTrustEngine.java:148)
Successfully verifiServer certificate verify failed: signer not foundidate) (BaseSignatureTrustEngine.java:101)
Attempting to establish trust of KeyInfo-derived credential (validateConnected to HTTPS on 34.196.133.252)
Failed to validate untrusted credential against trusted key (validate) (ExplicitKeyTrustEvaluator.java:95
org.opensaml.xml.validation.ValidationException: Signature did not validate against the credential's key
So it looks like something is being validated, but I do not understand why it's failing. I double checked with keytool and all the CA's are there.
Related
We are using IdentityServer4 and our version loads the signing key from a PFX file in file system or from the windows certificate store. Using the certificate works. The question is - which certificate issuer should be used in production?
Is a certificate from a public CA recommended? Or is it enough to have a self-signed certificate (without a CA at all) such as it can be created with IIS Manager?
In our tests we have found that the client could still validate the signature in the access token, even if the signing certificate would not have a valid CA chain on the client.
In the docs, it says that you can also use raw key material instead of a certificate:
http://docs.identityserver.io/en/latest/topics/crypto.html#token-signing-and-validation
In this scenario there would be no CA chain whatsoever.
That leads me to the assumption, that when the client loads the public signing key (via the HTTP(s) endpoint), the CA chain information might not be passed anyways. Is that right? Through the loading mechanism via HTTPs you also have a combined security mechanism.
So my conclusion is that for the signing credential a self-signed cert is just as safe as one from VeriSign. Can this be confirmed?
There is no certificate involved in signing and verifying the tokens. Only a private and public key (RSA or ECDSA key).
However a certificate can be useful to "import/transport" the keys into .NET. So, because of that we don't care about who issued the certificate.
When importing the key, one approach is to bundle the certificate that holds the public key + the private key and store it in a PKCE#12 file (.pfx/.p12 extension). Then load that file into .NET. Before .NET 5 working with keys was a bit hard.
The more important thing is that you can manage and deploy the private key in a secure way and that it is persisted over time.
Optionally, you can add support for key-rotation.
I built an Apereo CAS demo server with a WAR overlay (with which
different services should be authenticated).
I have set up delegated authentication with SAML2 (for integrating
with italian SPID system), following this guide
https://apereo.github.io/2019/02/25/cas61-delegate-authn-saml2-idp/
I copied the SP metadata to a IDP configuration.
This IDP is a test IDP instance, meant to check if SP metadata and the SAML request are ok.
When I run the server and I browse it,
I can see the second login form, but when I click it, the validation checks shows some errors.
Among them there is the following:
"The certificate must be signed with a valid algorithm."
"The certificate must not be signed using the SHA1 algorithm (deprecated)."
I am pretty sure that SHA-256 would be fine with the IDP validator.
In the documentation
https://apereo.github.io/cas/development/integration/Delegate-Authentication-SAML.html
I see that the following parameter should be in charge of specifying
the signing certificate algorithm:
cas.authn.pac4j.saml[].signature-algorithms:
Its description is
# Required: false
# Type: java.util.List<String>
# Owner: org.apereo.cas.configuration.model.support.pac4j.saml.Pac4jSamlClientProperties
# Module: cas-server-support-pac4j-webflow
# Collection of signing signature algorithms, if any, to override the global defaults.
# cas.authn.pac4j.saml[].signature-algorithms:
I don't know what values are allowed there. I googled a lot but with no luck.
I have tried to set that list like this
cas.authn.pac4j.saml[0].signature-algorithms=["sha256WithRSAEncryption"],
cas.authn.pac4j.saml[0].signature-algorithms=["SHA256withRSA"] but,
after clicking the SAML login button, I always get the following
error:
org.pac4j.saml.exceptions.SAMLException: org.pac4j.saml.exceptions.SAMLException: Could not determine the signature parameters
at org.pac4j.saml.crypto.DefaultSignatureSigningParametersProvider.build(DefaultSignatureSigningParametersProvider.java:60)
...
How can I specify a SHA-256 algorithm for signing the certificate?
I have a JWT issued by app.vstoken.visualstudio.com.
When I tried to do validate that token using
System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.Validate();
its throwing following exception
An unhandled exception of type 'Microsoft.IdentityModel.Tokens.SecurityTokenSignatureKeyNotFoundException' occurred in System.IdentityModel.Tokens.Jwt.dll
IDX10500: Signature validation failed. No security keys were provided to validate the signature.
I suspect its because its not able to locate the public key for the issuer having
thumbprint = x5t attribute value present in the JWT header
How to get that public certificate or how to tell JwtSecurityTokenHandler.Validate() to fetch the required certificate to validate the JWT signature.
My first approach was to validate token issued by remote website locally.
To validate locally I needed to validate signature of the token using public key of the remote website (since it has used its private key to sign the token).
But instead of doing that I found out that the remote website exposes set of rest apis accessing which requires user to provide valid token as part of "bearer" header in the http request.
Currently I am using that api to determine authenticity of the user.
The remote website was dev.azure.com and it exposes set of apis and sdk to authenticate the token.
Library used : Microsoft.VisualStudio.Services.WebApi
Could you please let me know how I can change the Resident metadata value to have a different certificate other than ws02 where I have signed a metadata using a specific cert. Seems IS is signing the SAMLRequest using its own cert so i get an invalid signature when sending a SAML Request to the Identity Provider.
I change the certificate alias on service provider configuration from IS console to the appropriate certificate but doesn't seem to overwrite signing it and still using the standard wso2 certificate.
Is there somewhere in the IS configuration where I can change the wso2carbon cert to one of my own so it will apply to identity provider resident?
Currently, the primary keystore configured by the / element in the /repository/conf/carbon.xml file is used for internal data encryption (encrypting data in internal data stores and configuration files) as well as for signing messages that are communicated with external parties. However, it is sometimes a common requirement to have separate keystores for communicating messages with external parties (such SAML, OIDC id_token signing) and for encrypting information in internal data stores. This is because, for the first scenario of signing messages, the keystore certificates need to be frequently renewed. However, for encrypting information in internal data stores, the keystore certificates should not be changed frequently because the data that is already encrypted will become unusable every time the certificate changes.
This feature will be available from IS 5.5.0 WUM and above. You can follow steps in [1] to configure multiple keystores.
<InternalKeyStore>
<Location>${carbon.home}/repository/resources/security/internal.jks</Location>
<Type>JKS</Type>
<Password>wso2carbon</Password>
<KeyAlias>wso2carbon</KeyAlias>
<KeyPassword>wso2carbon</KeyPassword>
</InternalKeyStore>
[1]https://docs.wso2.com/display/ADMIN44x/Configuring+Keystores+in+WSO2+Products#ConfiguringKeystoresinWSO2Products-second_keystore_internal_dataConfiguringaseparatekeystoreforencryptingdataininternaldatastores
I am trying to send a SOAP request(signed) using HTTP Request Sampler along with SOAP Message Signer plugin. Request works fine with SOAPUI. It seems to fail through JMeter if i use same parameters(for SOAP Message Signer).
As a part of SOAP Request, Header needs to be signed. I am getting the below error while Signing. Could anyone please let me know the reason for failure?
n.c.b.j.m.AbstractWSSecurityPreProcessor: Building WSS header
o.a.w.d.m.WSSecSignature: Beginning signing... ERROR
n.c.b.j.m.AbstractWSSecurityPreProcessor:
org.apache.wss4j.common.ext.WSSecurityException: No certificates for
user "cert_alias" were found for signature
Did you add in jmeter keystore the certificate under alias cert_alias?
That's what message is saying:
No certificates for user "cert_alias" were found for signature
Keystore is located in jmeter/bin folder
You may want to try this plugin:
https://github.com/tilln/jmeter-wssecurity/blob/master/README.md
Finally i was able to send a successful request using the plugin.
I was using the Signed Header as a part of SOAP request.
Plugin Config:
Keystore File : Path to .jks file
Keystore Password : password
Cert Alias - cert_alias
Cert Password - cert password
After removing the Signed Header from the SOAP request, it worked. Thanks you.
If your SOAP endpoint expects the message to be encrypted with a client-side certificate you can configure JMeter to use it by adding the next lines to system.properties file:
javax.net.ssl.keyStoreType=pkcs12 or jks
javax.net.ssl.keyStore=/path/to/your/jsk keystore or .p12 certificate
javax.net.ssl.keyStorePassword=your certificate or keystore password
JMeter restart will be required to pick the properties up.
You can also pass them via -D command line argument like:
jmeter -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStore=your-certificate.p12 -Djavax.net.ssl.keyStorePassword=secret
More information:
Customizing the Default Key and Trust Stores, Store Types, and Store Passwords
How to Set Your JMeter Load Test to Use Client Side Certificates