The SAML standard defines the ForceAuthn attribute of <AuthnRequest> as follows:
A Boolean value. If "true", the identity provider MUST authenticate
the presenter directly rather than rely on a previous security
context. If a value is not provided, the default is "false". However,
if both ForceAuthn and IsPassive are "true", the identity provider
MUST NOT freshly authenticate the presenter unless the constraints of
IsPassive can be met.
What I don't understand is whether ForceAuthn should only affect the service provider that's making the request, or whether it should require reauthentication globally as with single logout. What is the correct way to interpret ForceAuthn for SSO?
Based on the section quoted I would tend to interpret it as it is written. it does not say anything about a single logout being forced. instead it seems to indicate it is for the purposes of the AuthnRequest that includes the ForceAuthn attribute.
I would think that An AuthnRequest for one service provider should not invalidate the sessions of another service provider. The LogoutRequest is used for that.
ForceAuthn should only affect the service provider that's making the request
This is how I understand the ForceAuthn parameter, or more specifically only affects a specific AuthnRequest. You can have the following scenario:
Service Provider 1 sends an AuthnRequest with ForceAuthn = false. You need to log in. A login session is established.
10 minutes later, you access a functionality that requires high security. To make sure that it's you (and is not someone else who is using your machine while you are away), the SP sends you to the Identity Provider with ForceAuthn = true to force you to log in again.
You then access SP2. This one sends an AuthnRequest with ForceAuthn = false. You are logged in automatically thanks to SSO.
Finally, you access SP3. This application, due to its security policy, requires users to always log in, so it sends an AuthnRequest with ForceAuthn = true.
Related
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 having an issue with SAML 2.0 single logout.
I have a SAML 2.0 environment with an IdP (identity provider) and a web application acting as SP (service provider).
As user I start a web application session in an user agent (browser). The user is authenticated using the IdP.
In a different browser (running on the same client machine) I start another session as the same user in the same web application, i.e. in the same SP in terms of SAML.
Now I have two independent web application sessions where the same user is authenticated.
When I then perform a single logout initiated by the IdP in one of the browsers the IdP issues only one logout request which terminates the session that is running in that browser. The element of the logout request issued by the IdP equals the one that was sent by the IdP in the attribute SessionIndex of the AuthnStatement of the Assertion sent to the SP using that browser (user agent).
Wouldn't it actually be necessary for the IdP to send logout requests for all open sessions in order to achieve a true "single logout"?
Short answer: The SAML spec allows for Single Logout (SLO) to behave the way you want but a typical implementation isn't that sophisticated.
From SAML Profiles spec, section 4.4 (Single Logout Profile):
Once a principal has authenticated to an identity provider, the
authenticating entity may establish a session with the principal
(typically by means of a cookie, URL re-writing, or some other
implementation-specific means). The identity provider may subsequently
issue assertions to service providers or other relying parties, based
on this authentication event; a relying party may use this to
establish its own session with the principal. In such a situation, the
identity provider can act as a session authority and the relying
parties as session participants.
If the SLO sequence were to be initiated by one of the session participants, this whole discussion would be moot. The spec requires the session participant to identify the "shared" session being terminated via a unique ID (aka session index) that was originally sent to the session participant by the identity provider. As required by the spec, this ID will be different in your SP session #1 vs SP session #2.
...but when the SLO sequence is initiated by the IdP, your scenario is possible. Section 4.4.4.1 talks about the rules around issuing and processing <LogoutRequest>:
If the requester is a session participant, it MUST include at least
one <SessionIndex> element in the request. [...] If the requester is a
session authority (or acting on its behalf), then it MAY omit any such
elements to indicate the termination of all of the principal's
applicable sessions
Translation: if you could somehow tell the IdP to issue a <LogoutRequest> without a <SessionIndex> and your SP is sophisticated enough to correctly interpret such request and the SP can terminate all sessions for a particular user via its backend, then you've won.
In reality, the combination of conditions above is a very tall order. Out of the box, most IdPs will not issue a <LogoutRequest> without a <SessionIndex>. The very few SPs that even bother implementing SLO will not accept a request without a <SessionIndex>. In an extremely rare case where you'll be able to come up with a correct <LogoutRequest> and SP won't choke on it, you'll be very, very lucky if the SP correctly identifies all IdP-initiated sessions AND will be able to terminate them via the backend.
I started with Service Provider based SSO for SAML. Since the user had to enter his email before proceeding with the login, a state variable was initiated and passed on to the SSO. It comes back through the callback URL and hence was check again for the sanity purpose. It protected against CSRF attacks.
Now IdP initiated SSO doesn't allow me to set state variable at all. Login starts at Identity Provider and only an auth token is provided to the app. I do not know which user is authenticating from the beginning. If I remove the state variable check, it could trigger a CSRF attack as well.
I am also using omniauth in rails which makes state variable a compulsory param and SSO provider is auth0.
What is the way to attach state variable to IdP initiated SSO solutions?
The de-facto standard value of the RelayState parameter in IDP-init-SSO SAML flows is the URL that you want to send the user to after successful validation of the SAML assertion at the SP. That would work for the vast majority of SAML deployments out there.
However, that mechanism indeed does not protect against CSRF attacks this is why the spec is silent on the value of RelayState in IDP-init-SSO and leaves it open to agree on mechanisms between IDP and SP to prevent CSRF through the value of that parameter. One such mechanism would be to use a signed value in the RelayState but as said, nothing is standardized and it would thus depend on a bi-lateral agreement between IDP and SP which does not scale.
In summary: send the value of the URL that you want the user to go to as the RelayState value in the "unsolicited" SAML Response that you send to the SP. How you get the IDP's SAML stack to do that is implementation specific. For Auth0 you can read on this at: https://auth0.com/docs/protocols/saml/saml-configuration#idp-initiated-sso, and in your case it would look like:
https://{accountname}.auth0.com/samlp/YOUR_CLIENT_ID?RelayState=http://FINAL_DESTINATION_URL
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.
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