Steps to generate Signature Value in SAML Response XML - saml

I have a doubt about SignatureValue in SAML Response XML.
In some SAML tutorial I have read about Signature Value where we need to encrypt the SignatureValue using Private Key while sending to SP.
Do we really need to encrypt the SignatureValue at IDP side before sending to SP?
Because I was thinking that IDP will be sending the PublicKey to SP and SP will have the private key by which the payload can be verified at SP side whether there is any integrity issue.
Please need your valuable suggestion. Thank you in advance.
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#_SAML-11">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>asdfsf2342sdfsaf1123132123sdfsafsafsdf</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>TkjljjlkljllTlkjlsjdljslakfjlsnfl2352nlkn2k3l5lknln2l35nlnlnl2k3nk5lknlkn23l5</ds:SignatureValue>
</ds:Signature>

we need to encrypt the SignatureValue using Private Key while sending to SP
I've never heard of such a thing, and I can't think of a commercial SAML product out there that supports encrypting the signature (or decrypting it). I'll also note that it isn't mentioned whatsoever in the spec. Additionally, I can't fathom how encrypting the SignatureValue will help - with anything.
As the IdP, you need to properly handle signing the XML (which is the area that 95% of the DIYers mess up), and then you need to provide your service providers with the appropriate public key so that the signature can be validated.

The IdP should digitally sign the SAML Response using its private key. Its public key is normally published in its SAML2 metadata, which the SP should have. The SP can then validate the signature on the SAML Response coming from the IdP. If anything is changed between the IdP and the SP, the signature won't validate.
In addition, some SPs require the IdP to encrypt the attributes in which case they will be in an EncryptedAssertion node.
You can see these in the SAML examples.

I have an experience of integration with about 6 vendors (aka service providers) via SAML. And I want to note that some service providers may avoid specific steps and do not require the signature or encryption. For example, they might be OK to have both Assertion and SAMLResponse signed, but not having Assertion encryption. Or some other way.
I've published some more details here and also some C# code on GitHub that might help you to figure out how to do certain steps. Let me know if it helps.

Related

SAML IDP initiated SSO transaction

Webapp #1 has a button to webapp #2. When our users click that button, they should be redirected to webapp #2, and be automatically logged-in.
The integration is SAML, so webapp #1 (the IDP) sends a SAML "request" to webapp #2 (the SP), which returns a redirect URL, and webapp #1 redirects to it.
The SP gave me a URL to HTTP POST an assertion identifying the user via the "email" attribute, so I produced this:
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" IssueInstant="2021-12-22T16:59:43.999Z" Version="2.0"><saml2:Issuer>http://www.whatever.com</saml2:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMethod><ds:Reference URI=""><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform><ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod><ds:DigestValue>...</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>...</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2:Conditions><saml2:OneTimeUse></saml2:OneTimeUse></saml2:Conditions><saml2:AuthnStatement AuthnInstant="2021-12-22T16:59:44.053Z" SessionIndex="cfb8f9b5-9616-47db-bc92-7588ce18cf62" SessionNotOnOrAfter="2021-12-22T16:59:44.068Z"><saml2:AuthnContext></saml2:AuthnContext></saml2:AuthnStatement><saml2:AttributeStatement><saml2:Attribute Name="email"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">si#captisintel.com</saml2:AttributeValue></saml2:Attribute></saml2:AttributeStatement></saml2:Assertion>
The SP responds with a 302 and a Location header that looks like this:
Location: ?SAMLRequest=nVNNj9owEP0rke%2FkS4VtLc...
Decoded:
<?xml version="1.0"?><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_f848f04c71671a745722" Version="2.0" IssueInstant="2021-12-22T18:36:19.337Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://auth.whatever2.com/saml/callback" Destination=""><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">whatever2</saml:Issuer><samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/><samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact"><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></samlp:RequestedAuthnContext></samlp:AuthnRequest>
When I visit that URL, I am presented with the login page.
So this is not working.
I have 0 visibility over the SP logs to know what's wrong. All I can guess is that I am not posting this correctly. So does this look right, or should I post this differently? I tried posting the Assertion in the body as-is, wrapping it in a "<samlp:Response" envelope, wrapping it plus prefixing it with "SAMLResponse=". I tried each plain and deflated/base64 encoded.
Another clue is that the SP always returns a 302, no matter what I send them. Even if I send "BLAHBLAH" and not an actual SAML payload, they still respond with a 302.
Any advice?
In a IdP initiated flow, the IdP sends the SAML Response containing a Assertion in a POST like you do. If all goes well the SP should now consider the user authenticated.
The SAML response should be sent in input control named SAMLResponse and should be Base64 encoded.
<input type="hidden" name="SAMLResponse" value="<Base64 encoded SAML Response>"/>
I would guess that what happens is that for some reason, the SP does not accept your SAMLResponse and instead starts the normal SP initiated SAML flow by sending a SAML request to the IdP to authenticate the user.
Why your response is not accepted can be many things. Without the SP logs we can mostly guess.
Off the bat I see that you assertion is missing a Bearer subject confirmation which is mandatory.
From the SAML Profiles spec 4.1.4.2
Any assertion issued for consumption using this profile MUST contain a element with at
least one element containing a Method of
urn:oasis:names:tc:SAML:2.0:cm:bearer. Such an assertion is termed a bearer assertion.
Bearer assertions MAY contain additional elements.
There is also more requirements on the assertion in the same chapter
Some other ideas though:
You should have your assertion in a SAML response, but there are several boiler plate elements that need to be set. So ensure it is valid
It is not unusual to see that the response message itself must be signed and not just the assertion.
I would suggest having a look at the SAML profiles spec 4.1.4.2 to understand what assertion and response must contain.
And also, try agian to see if you can get any feedback on whats wrong from the SP to avoid banging your head bloody doing blind try and fail.
SAML is not the most stright forward protocol there is and there is a lot to get right to get it working and get it secure. As I always try to say to people starting out with it: Dont build it your self, there is alot of good opensource alternatives out there for doing SAML that will make your system so much more secure and maintainable.
If you want to get a better understanding of SAML and how to implement it I can recommend my book, SAML 2.0: Designing secure identity federation
Good uck!
You should be sending a SAML response containing a SAML assertion to the SP rather than just a SAML assertion. You also need to ensure this is encoded correctly as per the SAML v2.0 Bindings specification.
You really need the SP to assist with the debugging. Hopefully their logs will provides details as to why they're rejecting your HTTP Post.

How OpenAM verify SAML response coming from IDP

is OpenAM depends on the public key of the registered IDP to versify the SAML response
or depends also on the hashing algorithm in the SAML response from IDP
like Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
Note OpenAM version :13.0.0
OpenAM, acting as SAML SP, uses the public key enclosed in the KeyInfo element of the IdP meta data to verify the signature of the SAML response. It uses the signature algorithm chosen by the IdP, however it must be a supported signature algorithm.
In upcoming versions of AM, AM will (partially) implement the algsupport spec, and will take into account remote entity provider's metadata when signing SAML documents.
This means that as a hosted entity provider, AM will check the remote entity provider's preferred signing and digest methods, and will use the first algorithm that satisfies the key type and key size requirements.
This work has been completed as part of OPENAM-11266.

SAML workflow question regarding certificates

I have a question regarding saml workflow when certificates are being requested from the SP.
We are a SP and have implemented sso using saml for a number of customers. We send a standard request (doesn't include any certificate, or request isnt signed) to the clients IDP and handle their response validating their x509 cert which was shared pre-release and have installed on our server.
This is the only work we do with certificates at the moment. We now have a client who is asking for our x509 cert. We currently dont have a certificate, and i'm wondering what changes in our current workflow based on this request.
Do we need to sign our initial response or add the certificate into the body of the response? I'm a little in the dark to whats required from our end and what changes were going have to make.
It clearly is adding some other layer of security but could someone explain the workflow when this extra signing is used ?
Thanks in advance.
They probably want to encrypt the SAML Response containing attribute statements, etc. They would use your public key (i.e. the SP's certificate) to encrypt the payload, and then you (as the holder of the SP's private key) would be the only one that could decrypt that content.
This is a perfectly reasonable request from the IdP.
And realistically, you should be signing your AuthnRequests and LogoutRequests with a certificate. You don't need to provide the encryption cert in the AuthnRequest, the IdP will use the cert in the metadata to encrypt the content.

How can I pre-fill email for SAML Google IDP?

We're using SAML 2.0 for SSO, and want to improve the UX by allowing a user to enter their email only once (to identify they need SSO). Is it possible to pre-fill the SAML SSO email field when authenticating with Google's SAML IDP?
I know that the AuthnRequest has an optional Subject field that can pass the principal information to the IdP, but so far I haven't managed to have Google's SSO form pre-populate. Either it's not supported from the IdP, or I'm sending the wrong configuration.
The existing configuration I've been trying to use looks like this:
<AuthnRequest xmlns="urn:oasis:names:tc:SAML:2.0:protocol" ID="_cd...." Version="2.0" IssueInstant="2019-01-01T00:00:00Z" Destination="https://accounts.google.com/o/saml2/idp?idpid=...">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">(issuer_name)</saml:Issuer>
<Subject xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">me#example.com</NameID>
</Subject>
</AuthnRequest>
I would expect the Google SSO form to autopopulate me#example.com, but nothing happens.
The Subject element is optional in an authentication request and even when included, it's ignored by most IdPs. Since authentication request can be sent to the identity provider by an anonymous party, performing a UX action like you're thinking about would certainly lead to an easy phishing vector.

Google Apps as SAML IdP

I'm trying to configure Google Apps as SAML IdP with Zoho as service provider.
After authentication, the SAML response xml from Google always contains NameID Format as unspecified.
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">email#company.com</saml2:NameID>
Google Apps does have the option to change the NameID Format. Refer this screenshot :
Service Provider details
But even if EMail is selected as NameID Format, the above response is present in SAML Response xml.
The expected NameID Format in response is as follows :
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">email#company.com</saml2:NameID>
Is there a way to achieve this ?
Check if Zoho-SP sends <AuthnRequest /> with Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" to Google-IdP. If yes, send <AuthnRequest /> with Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" from Zoho-SP side and try.
Setting NameID format in IdP is for default configuration. That setting won't be taken, if AuthnRequest specify which NameID format to used to identify the user between IdP and SP, upon authentication.