When returning SAML Response to SP, most IdP like AzureAD, Okta, Onelogin, GSuite have the following options about signature:
sign Response
sign Assertion
sign Response and Assertion
And without any configuration, for most IdP, the default for signature is to only sign Assertion.
Below is a SAML Response example from AzureAD (the default signing option is sign Assertion). The Assertion is integrity protected and no tampering can be done. However fields other than Assertion, Destination InResponseTo Issuer, can be tampered with, or add/remove without knowledge!
So my question is:
Why there are 3 kinds of signing? (Response, Assertion, Response & Assertion)
In which use case should we choose to sign the whole Response, sign the Assertion or sign both Response and Assertion?
By only signing Assertion (as default by most IdP), do we exposed to any vulnerabilities?
Check Scott's answer from the SOF post
The only requirement for the IdP following the SAML 2.0 spec is to
digitally sign the Assertion (see
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
section 4.1.3.5). That is enough to tell if the SSO operation from an IdP should be trusted by SP that has federated with it.
Signing the outer Response is optional. There are some security
benefits to it, such as preventing Message Insertion or Modification
(see sections 6.1.3/6.1.5 in
http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf) - but in practice it's often omitted in lieu of relying on SSL/TLS.
Since the Assertion is part of the SAML response, it would be enough to sign the SAML response only. This way you can secure/sign the entire SAML authentication response.
By signing assertions you only sign the attribute statement within the response.
By only signing assertions, I don't think that we expose to any vulnerabilities since the important information is within the assertions in SAML response.
Most of the IDPs have configuration options to handle signing as per the requirements in SP.Also if you are building your own IDP you can implement it to suppo
Related
Integrating one of my application with with SAML 2.0 single sign on. Using Okta provider for this. I came to the point where I receive base64 encoded "SAML response token" after successful authetication in okta and redirected back to my application. Within this token I see all the user details I need but here comes my question. Do I need to verify that response any futher or shall I just trust what I receice? Considering this token also contains signarure?
My idea for security would be to reach Okta again and verify if this was really issued by Okta. Not sure if this is even possible.
Using NodeJS for verification.
If by SAML response token you mean the samlp:Response issued according to the Web Browser Passsive SSO profile then then response contains an assertion and the assertion is signed by the Identity Provider (additionally, the whole response can also be signed).
There's a critical security requirement to always validate the response signature. This is mentioned in the SAML specs, section 4.1.4.3
The reason for this is as follows: in the Web Browser SSO Profile the token is returned by the Identity Provider in a web page that contains a simple form with SAMLResponse and RelayState fields and a bit of code that just autoPOSTs this form to your app. Technically, this means that for a short time the token is controlled by the user's web browser and this is where the token can be altered (or forged).
Thus, the protocol security heavily relies on the token's integrity which is achieved with the crypto signature - it's just a plain old XMLDSig signature applied to the SAML.
Your goal, as a token receiver is not only to validate the signature but also check the signature's certificate and compare it to the certificate you expect from the trusted provider (or a list of certificates of trusted providers).
Skipping this step makes your application vulnerable:
skipping the verification means users can alter the token (add/create/delete) claims to the assertion, the signature verification would fail but you skip it
skipping certificate matching against known certificate means users can forge their own assertions, sign it using a dummy certificate and present to your application. The signature verification step would succeed but you won't be aware that a dummy certificate was used to sign the assertion
If you don't want to do the proper token validation on a backend (don't blame you, it's a pain), then switch to OIDC. That's a better fit for authentication and authorization for the frontend.
If, however, the SAML response is sent to and handled by a backend, and some other token is being forwarded to your application, then you should evaluate what the requirement for the validation of that token is.
What isn't clear in your question is where in the user flow we're talking about, hence the number of comments on my answer.
So I am implementing SSO over SAML2.0 for our application. We are using saml2-js on our side and we are doing SP initiated SSO.
The implementation is ready and it is working however there are a few parts I struggle wrapping my head around.
saml2-js requires you to provide a private-key and a certificate on the ServiceProvider instance -> https://www.npmjs.com/package/saml2-js#serviceprovideroptions I don't understand what these are used for and saml2-js don't provide any meaningful description about them. I tried to find out by understanding from a SAML point of view but I still don't know.
As an IdP, Okta is the target and after setting up SAML in Okta, Okta provides it's certificate. Now I understand that part because Okta will sign the Response and on our side, the SP uses that certificate to ensure that the Assertion came from a/the trusted party. But how does Okta make sure that the request came from a trusted party? I thought the certificate saml2-js requires from us will be used for that, but as it turned out this assumption was false because Okta doesn't get our certificate in any ways
When setting up SAML in Okta (okta guide) in point 6 they require you to fill the Audience URI which by default is the SP entity_id. But this can be an arbitrary value right? What is this used for and why is this mandatory?
The service provider requires a private key if it's signing SAML messages or decrypting SAML assertions. If neither is the case, a private key shouldn't be required.
I don't believe Okta requires the SAML authn request to be signed. This isn't unusual. If the SAML authn request isn't signed, the IDP can't be sure who sent the message but this normally wouldn't present any security issues. If you click the Show Advanced Settings link in the Okta configuration you get the option of supplying your certificate. However, this is only required for signing the logout messages.
The audience URI identifies the intended recipient of the SAML response which should be the SP. It's part of the SAML protocol and as such you would expect the SP to check its value against the SP's entity ID. If you take a look at the SAML specification it talks about its purpose as helping to uphold warranty exclusions in a court of law. You can draw your own conclusions as to how useful this is.
I'm using the standard SAML 2.0 SP-initiated SSO protocol for authentication.
Normally the IdP returns a samlp:Response XML object to my SP, containing a saml:Assertion about the authenticated user.
Does the SAML spec allow the IdP to return a response to the SP that doesn't contain user information?
I'd like handle the situation where authentication couldn't be done, but we want to return to the SP's site. Maybe the IdP could return some kind of error or message to our SP? Right now it seems like if authentication is impossible, the user is stuck on the IdP's site.
I guess they could just redirect to an agreed-upon URL, although then you would lose the RelayState information. Would that be the right approach, or does the SAML spec handle this scenario?
The SAML2 spec handles this. The Idp can return a samlp:response with a status code of Responder meaning that the idp failed to fulfill the request. Then there can be more detailed status information on exactly why.
But the case where an Idp fails to authenticate the user can be handled in the protocol. However, I think that most Idps behave as you describe - keep the user on the Idp if things goes wrong.
Added by OP — this is from the SAML spec:
<StatusCode> [Optional]
A subordinate status code that provides more specific information on an error condition. Note that responders MAY omit subordinate status codes in order to prevent attacks that seek to probe for additional information by intentionally presenting erroneous requests.
The permissible top-level values are as follows:
urn:oasis:names:tc:SAML:2.0:status:Success
The request succeeded. Additional information MAY be returned in the and/or elements.
urn:oasis:names:tc:SAML:2.0:status:Requester
The request could not be performed due to an error on the part of the requester.
urn:oasis:names:tc:SAML:2.0:status:Responder
The request could not be performed due to an error on the part of the SAML responder or SAML authority.
urn:oasis:names:tc:SAML:2.0:status:VersionMismatch
The SAML responder could not process the request because the version of the request message was incorrect.
In the case of IDP Initiated FLow, Is the AuthnStatement is also mandatory in Assertion of the SAML Response?
Edit:
And what is bearer Assertion and what is its use?
As far as we are talking about the Authentication Request Protocol which is used in Web Browser SSO Profile for both SP and IDP initialized single sign-on, the standard has the followng to say:
In case profile doesn't override) The assertion(s)
returned MUST contain a element that represents the
presenter. The identifier type and format are determined by the
identity provider. At least one statement in at least one assertion
MUST be a that describes the authentication
performed by the responder or authentication service associated with
it. (2250-2253 core)
and
The set of one or more assertions MUST contain at least one
that reflects the authentication of the principal to
the identity provider. (547-548 profiles)
So the answer is - depends on profile, some SAML profiles (including custom ones) may not require AuthnStatements, but the most typical SAML profile for web single sign-on (and the one you are most likely talking about) does require it for both SP and IDP initialized flow.
And to your second question - bearer assertion is such assertion which is using bearer subject confirmation.
Subject confirmation is piece of information which helps recipient of the assertion (relying party / service provider) verify that the presenter of the assertion (attesting party - e.g. browser, or API client, ...) is associated with its subject (about whom was the assertion issued) and authorized to present the assertion on subject's behalf (to make sure that someone cannot use assertion issued for someone else, without someone else's permission). The bearer subject confirmation simply means that the presenter of the assertion is the same as the subject.
Few things are mandatory in SAML. Accordning to SAML AuthnStatement is not mandatory in any assertion. This is probably constrained in some way in the software you are using. If it is mandatory for Assertions in SP init flow I would guess it is mandatory in the IDP init flow to
Our app has SAML2 SSO integration with 3 different (Shibboleth) IdP's. We are trying to add a 4th (also Shibboleth), but running into some issues, because our app expects all SSO responses to be verifiably signed. These other 3 are signing their responses, but the 4th is not, and is hesitant to add a custom config to enforce signing for our app.
Technically I could modify our app to accept unsigned SSO responses, but I am wondering whether or not I should. What are the pitfalls of allowing unsigned SSO responses? Is there any security vulnerability?
Is there any Shibboleth (or other SAML2 SSO) documentation that recommends signing responses as a best practice?
The only requirement for the IdP following the SAML 2.0 spec is to digitally sign the Assertion (see http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf - section 4.1.3.5). That is enough to tell if the SSO operation from an IdP should be trusted by SP that has federated with it.
Signing the outer Response is optional. There are some security benefits to it, such as preventing Message Insertion or Modification (see sections 6.1.3/6.1.5 in http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf) - but in practice it's often omitted in lieu of relying on SSL/TLS.
The whole point of signing the response is to prove that they actually do come from the issuer. Otherwise a "man in the middle" could change the attributes e.g. to give themselves access to an application.
ADFS v2.0 using SAML by default signs all response tokens. There's no way to turn this off.