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.
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 have a saml response that gives me azure active directory when doing the process with saml 2.0, the whole process is done normally, I send a saml request and the azure active directory returns the saml response, to do the whole process I have based on this guide, I've been reading a bit and I've noticed that Azure AD in the saml response sends the values within this tag:
<xenc:CipherData>
<xenc:CipherValue>VALUE HERE</xenc:CipherValue
</xenc:CipherData>
And not inside:
<AttributeStatement><Attribute Name="IDPEmail"><AttributeValue>administrator#contoso.com</AttributeValue></Attribute></AttributeStatement>
as specified in the documentation. The question is, how to get the true values that azure active directory is sent to me and not these encoded values, I am using Python 3 and Google App Engine, in addition to mentioning azure active directory and saml 2.0 to do the login process, I leave the SAML response complete in this url in case it serves to give a better context to my question.
As mentioned above, the SAML response you are getting is encrypted. Specifically Azure is encrypting its assertions (including the ones you are looking for) inside an encrypted body called CipherData.
You have two options:
1 - Disable SAML response encryption.
Azure AD calls SAML response encryption as SAML token encryption which is a bit confusing. You can follow this guide to disable the response. You must have uploaded an encryption public key/cert before.
2 - Configure your service provider to supported encrypted SAML responses.
The SAML token is encrypted.
You need to get the client side certificate used for this and use that to decrypt it.
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).
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.
SAML assertion is generated at the IDP(PF). It is consumed at the SP(PF). Is saml assertion tampering possible? If so, how to test it? I am trying to track get & post requests.
When I post the generated SAML Response to https://machine_name:port_no/sp/ACS.saml2, I get 404 error. I understand that we cannot hit the url.when I give the destination resource url, the resource page is opened.But I don't find the response in my server log.
I want to post the generated response with slight modifications and test if it throws any error. The intruder shouldn't be allowed to get the resource. Though I modify the response, I am able to hit the url & access the page.I am using POSTMAN chrome extension for this purpose.
Note : I am extracting saml response from the Agentless Integration Kit sample application.so the destination url is https://machine_name:port_no/AgentlessIntegrationKitSampleSP
Thanks,
Aswini J
If you want to tamper with the SAML data in the browser, you should use the Tamper Data extension for Firefox. It will allow you to step through each transaction and selectively modify the data.
However, you cannot successfully tamper with the SAML Response because it is a digitally signed (and optionally encrypted) message. Any tampering of the signed data will invalidate the message and PingFederate will not allow the message to go through. This is mandated per the SAML XMLDig specification which PF strictly enforces.
The info exchanged between the PingFederate (SP) and QuickStartApp (SP) is not SAML -- it is a "one time use" reference token that refers to information that is stored in PingFederate runtime memory. If you modify this value, PF will throw an error because it will not reference any known data.