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
Related
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
I am looking for a way to tie the SAML request I make to an IDP to the SAML Assertion it sends back. Is there a way to do that?
One idea I had was to use the SessionIndex. I have found that in practice, in some cases the SessionIndex can be used to do this, because some SAML servers return the ID from the initial request as the SessionIndex in the SAML Assertion, but I have also found that is not done universally / does not seem to be required by the spec. It seems like the intention of the SessionIndex is just to tie together the SAML Assertion with subsequent calls, e.g. logout attempts, so there's no requirement that it be tied to the initial request. I draw that conclusion from this post, which says "At least one assertion containing an MUST contain a element with at least one element containing a Method of urn:oasis:names:tc:SAML:2.0:cm:bearer. If the identity provider supports the Single Logout profile, defined in Section 4.4, any such authentication statements MUST include a SessionIndex attribute to enable per-session logout requests by the service provider." I have also reviewed this post, which breaks down the use of SessionIndex and I think supports the same conclusion.
I don't see anything else in the spec that seems promising, but I am hoping I may be missing something - is there any reliable way to pass data to the IDP in a SAML request and get it back in the SAML Assertion?
FYI, the reason why I want this is to support mobile sso login where my mobile device uses an embedded web browser to make an OAuth2 call to my web server, the web server authenticates the user, and then sends back an authorization code to the mobile device with a redirect. I want to use PKCE to secure the OAuth2 flow between the mobile device and the web server, but that requires me to be able to tie the initial request call to the final redirect with a shared code.
There are at least two methods that can be used, so long as the user journey starts where it should, on the page they are trying to get to, making this a service-provider initiated authentication request. As the service provider in a SAML-based federation, you start the process by sending the identity provider an AuthnRequest.
The first method availables comes by tracking the AuthnRequest's ID. In a good SAML implementation, that AuthnRequest's ID is big and random and likely not repeatable in our lifetime. The SAML Profiles spec says on lines 625-626:
If the containing message is in response to an <AuthnRequest>, then
the InResponseTo attribute MUST match the request's ID.
Therefore, as long as you keep track of the ID's that you send out, then you can tie the Request's ID to the Response's inResponseTo.
The second method at your disposal is RelayState. This is an aptly-named element of an AuthnRequest that you can use to transfer state to the Identity Provider an back. This is a field that you can use as you see fit as the service provider, and the responder has to send it back. The Bindings spec says on lines 265-271:
Some bindings define a "RelayState" mechanism for preserving and
conveying state information. When such a mechanism is used in
conveying a request message as the initial step of a SAML protocol, it
places requirements on the selection and use of the binding
subsequently used to convey the response. Namely, if a SAML request
message is accompanied by RelayState data, then the SAML responder
MUST return its SAML protocol response using a binding that also
supports a RelayState mechanism, and it MUST place the exact
RelayState data it received with the request into the corresponding
RelayState parameter in the response.
As such, you can put something in that field, and the IdP must parrot it back untouched. You should make sure that what you put in there doesn't compromise the user or security, so just be mindful of how you use it. It's going to end up in logs somewhere.
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.
I!ve a question similar to How To Become a SAML Service Provider, but it misses some part I would like to clear up.
The SAML SSP profile spec describes several possible bindings, and states that the usage depends on SP and IdP setups.
The SAML Conformance and Profiles specifications identify the SAML
bindings that can legally be used with these two messages.
Specifically, an Authentication Request message can be sent from an SP
to an IdP using either the HTTP Redirect Binding, HTTP POST Binding,
or HTTP Artifact Binding. The Response message can be sent from an IdP
to an SP using either the HTTP POST Binding or the HTTP Artifact
Binding. For this pair of messages, SAML permits asymmetry in the
choice of bindings used. That is, a request can be sent using one
binding and the response can be returned using a different binding.
The decision of which bindings to use is typically driven by
configuration settings at the IdP and SP systems. Factors such as
potential message sizes, whether identity information is allowed to
transit through the browser (if not the artifact binding may be
required) , etc. must be considered in the choice of bindings.
The first question I have: as a Service Provider, am I free to choose any one of the SP -> IdP bindings, and it will work with any IdP out there, or I should make this configurable in my implementation and support all the bindings? (Nota bene: I will probably integrate an existing saml library to help my life, but I should know what configuration options should I allow and support on my interfaces.)
The second question is about the SamlResponse coming back from the IdP upon successful authentication. As far as I understand, SAML just tells me that the user suucessfully authenticated with the IdP. As a result I would expect to give me back some user identifiers in the Response, like a uid, username or e-mail address that I can query from a local user db or LDAP and run app-specific authorization logics.
How can I ask the IdP the user identifier I need and how/where will it be returned? I can't see anthing related to this in the Wikipedia example
Depending on what bindings your SAML-IdP and SP server supports, you can choose any combination of binding pair. Typically all major SAML-IdP supports most of binding specified in SAML-spec. Also you have to take security and performance considerations. Artifact is more secure but take two round-trips to complete SAML-Authn process, because it make back-end call communication (unlike POST or Redirect) while sending and receiving SAML messages. If your SAML-IdP and SP server supports binding configuration, then you use those bindings in runtime.
NameID format identifies user between IdP and SP, which is sent in SAML Assertion by IdP. It can be emailAddress, unspecified, transient, persistent and few others. Check Section (8.3) Name Identifier Format Identifiers from SAML Spec for more details. Also you could request IdP to send user attributes (that exist in IdP identity-store) in SAML Assertion.
My understanding of the SAML (v2) protocol is that Service Providers should be interacting directly with Identity Providers to exchange authorisation request and assertion messages.
I can think of a number of reasons why this would be a bad idea (undermines message signing, gives intermediate IdP access to info from other IdP), but are there any scenarios supported by SAML that would allows the following arrangement?
SP <------> MainIdP <------> ThirdPartyIdP
So (hypothetically) assuming that MainIdP has some clever way of determining that the SP user needs to authenticate against ThirdPartyIdP, it would delegate to the ThirdPartyIdP and then receive the response, process it and reply to the SP. Does SAML allow this? (I am asking because a software supplier has suggested this approach and I believe it isn't supported, as well as being fundamentally insecure.)
The "correct" approach as I understand it is for the SP to be configured to know about both IdPs independently, and either present the user with a list to pick from, or delegate to a Discovery Service which can ask the user, or infer by some other means, which IdP to use. Is this right?
Thanks.
Most federation identity providers for SAML have the concept of a "Home Realm Discovery" screen.
The SP is "bound" to the MainIdP but the MainIdP presents a screen which shows all the other IDP's that it is federated with. From that list, you pick the ThirdPartyIdP.