I would like to ask if I signed the saml response with idp private key and encrypt saml assertion with sp public key. Do I need to sign the saml assertion before encryption? Is it overkill? Do you know any standard from any official doc? Thanks.
Encrypting with the recipient's public key guarantees that only the recipient can read the contents. Anyone can encrypt data with the recipient's public key.
Signing with the sender's private key guarantees that only the real sender could have created the data. Anyone can validate that the data is indeed from the sender.
In SAML the most important thing for an SP is to being able to validate that the assertion is indeed from the IDP and not from some fake source. That can only be done through signing with the IDP's key. That's why signing is mandatory in the SAML standard. Encryption can be used to make sure nobody but the SP can read the contents of the assertion. That is optional in the standard.
For details see chapter 5 in the SAML2 core specification.
The best method is to encrypt and then sign the entire SAML response rather than just the assertion. This method is considered to be most secure and will be more widely accepted by SSO/Federation products.
The reason for signing the entire SAML response is a potential protocol vulnerability, where the origin of the SAML response could not be guaranteed (if the response itself weren't signed).
Related
I have a basic question on setting up trust between a SP and IDP.
Usually a two way trust is required when we setup an IDP with SP by uploading certificates on either side.
Is signing certificate from SP mandatory to be configured in the IDP side ?
Best Regards,
Saurav
You only need a signing keypair on the SP side if you send the subject in the AuthnRequest, and your IdP utilizes the information when provided. If your SP isn't sending the subject attribute or your IdP won't consume it, you don't need it.
The defined SAML 2.0 specifications doesn't mandate that the request is signed.
4.1.3.3 <AuthnRequest> Is Issued by Service Provider to Identity Provider
...The <AuthnRequest> message MAY be signed, if authentication of the request issuer is required.
You can check with your Identity Provider documentation, but for example, Microsoft Azure AD does not validate signed requests, and there's no way to upload a request signing certificate.
I am trying to sign my HTTP-Redirect binding AuthenRequest so I can send it to the Idp. What is the logic behind signing the request? Do I sign it using my x509 and a private key? Do I sign it using my private key and Idp's x509 cert? Also, the Idp requires the signature query parameter. Do I simply extract the signature value from the request after I sign it?
I am developing in c# .net
Thanks
You always sign with your private key. The recipient will verify the signature using your public key.
In this case, you sign the SAML authn request with your private key and the identity provider will verify the signature with your public key.
Typically you supply the identity provider with your public key as a certificate file or as part of your SAML metadata.
If the IdP requires the signature as part of the query string, this means they want you to use the HTTP-Redirect binding to send the authn request. You need to look at the SAML v2.0 bindings specification to understand how to implement this. The signature is not part of the request and therefore isn't extracted from it.
The best and easiest solution to get the proper Signature value in HTTP-Redirect post is to use a 3rd party library for c# called ComponentPro. Below is what I used to get it to work:
NameValueCollection queryString = RedirectUtil.CreateQueryString("SAMLRequest", authnRequest.GetXml(), relayState, key, signatureAlgorithm);
The key is the private key.
I'm facing a problem with validating SAML response where in, its giving digest mismatch. Tried checking it with the certificate's digest value and its showed a different value. I think there is a problem with the certificate or the SAML response but, I'm also wondering whether not having an authentication at the SP level is also a cause for concern since, the client does not want a response back on the IDP, contrary to what the standard setup for SAML dictates. I realize there shouldn't be a setup of this sort due to obvious security concerns but, this was the setup they have requested...
If the SAML assertion is not signed properly, this is a security concern and you should not trust it. By trusting it without validating the digest, you would open your self up to anyone submitting SAML to your ACS URL and being authenticated.
After successful authentication,which is done by identity provider,How Secure Assertion Markup language 2.0 request is generated for that user and what does it contain?
How the assertion is generated is up to the IDP. What it contains it ultimalty the IDPs decition too.
In the SAML Assertion spec you can read what it can contain. Chapter 2 has a good summary
To know specifically what your IDP provides you would have to talk to them.
I am just wondering while implementing SAML SSO with Salesforce I realize that I uploaded the certificate to the SP side (i.e. Salesforce), however I can see when we send a signed SAML response it already includes the certificate.
Why is the certificate shared ahead of time with the SP?
It's all about establishing trust between systems. If you don't give SFDC your cert ahead of time, how can they trust the message you are sending is actually from your IDP? Without your cert ahead of time, they can validate that the message is intact but not who actually generated it. When you include your public key in the SAML Response, they can check that it's the same one you shared with them and it's the same one you used to generate the signature.