I am new to the concept of Single Sign On(SSO). I came to know that SAML request and response is the best way to achieve SSO process. I then started reading about SAML2.0. I came around a term NameIdPolicy in saml2.0 which was not there in saml1.0.
Definitions say that It is the format of the NameID we request from the IdP.I want to know what is that format is? I mean what data from IDP should come in the format NameIDPolicy specify? Can anyone brief me on this NameIdPolicy concept?
From the SAML 2.0 core spec, the NameIDPolicy
Specifies constraints on the name identifier to be used to represent the requested subject. If omitted,
then any type of identifier supported by the identity provider for the requested subject can be used,
constrained by any relevant deployment-specific policies, with respect to privacy, for example.
When performing identity federation, the affiliated parties must agree upon an identifier for the principal's linked accounts. The identifier string is called a NameID and its specification, including format, is the NameIDPolicy.
For example, a Service Provider (SP) initiates federation by sending an AuthnRequest to the Identity Provider (IDP) containing
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
This tells the IDP that its response Assertion XML should contain something like
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user#example.com</saml:NameID>
where the email address represents the subject being authenticated.
You can learn more by reading SAML 2.0 Wikipedia page (well-written), the SAML 2.0 core spec and the SAML 2.0 Name Identifier document.
Related
I'm reading the SAML specification and experimenting with Keycloak and Shibboleth IdPs and I'm not sure how to implement one feature in an SP-initiated login.
I have a service that traditionally used to have an SP status information displayed on its login page (e.g. application version, status). After switching to using an IdP login page I'd like to keep displaying such per-SP additional information on the login page of the IdP. I'm interested in the data exchange, not in templating the login page itself.
Does SAML 2.0 specification allow for sending arbitrary data to the IdP for the purpose of logging in? If not, what are other options that can be used to decorate IdP login page using SP-generated data?
Sort of. The authentication request from SP to IdP is allowed to have "custom" extensions (the Extensions parent element), the content of the extensions is up to you. From the spec:
[Optional] This extension point contains optional
protocol message extension elements that are agreed on between the
communicating parties. No extension schema is required in order to
make use of this extension point, and even if one is provided, the lax
validation setting does not impose a requirement for the extension to
be valid. SAML extension elements MUST be namespace-qualified in a
non-SAML-defined namespace.
If you're writing your own IdP, you could certainly make use of Extensions and do whatever you wish with it. "Standard" (commercial/OSS) IdPs won't know what to do with your extension. It'd be an interesting test to see if Shibboleth or Keycloak libraries parse the Extensions element and give you the contents.
The other, more standard possibility is using RelayState. This is a spec-compliant way of passing some provider-specific state information around, incl. from SP to IdP:
3.1.1 Use of RelayState 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.
Again, all IdPs or downstack libraries will parse RelayState but how they handle it from there depends on their reading of the spec. For one, the spec requires RelayState to be 80 bytes and integrity protection via a signature or "other means". This limitation is often ignored by IdPs and SPs.
What SP-specific information are you trying to display on IdP login page?
The only thing that an SP can send to the IdP is the Subject (see lines 585-589 of the spec).
So I'm trying to integrate single sign-on with Auth0 (being both the service provider and the identity provider) with the Atlassian stack.
Atlassian offer SAML single sign-on. However, it is telling me:
Your users won't be able to log in with SAML single sign-on until you've copied
the values for SP Entity ID and SP Assertion Consumer Service URL to your
identity provider.
I've put the assertion consumer service URL in place of the callback URL, I've done some research and I'm almost certain this is correct.
However, the issue is with the Entity ID. Where does this go?
I've not used Auth0 before, but I think you have to set it as audience in the settings, e.g. see https://auth0.com/docs/protocols/saml/saml-apps/heroku
IMHO but the configuration option is a bit misleading. Instead of using audience, using EntityID might be clearer, as this is also the term used in the SAML spec.
I am assuming that auth0 acting as a service provider.
Assertions Consumer service URL should be :
https://YOUR_DOMAIN/login/callback?connection=YOUR_CONNECTION_NAME
Entity ID of the service provider should be:
urn:auth0:YOUR_TENANT:YOUR_CONNECTION_NAME
You can download service provider metadata like below in the XML format and upload to IDP to generate configuration.
Navigate to https://YOUR_DOMAIN/samlp/metadata?connection=YOUR_CONNECTION_NAME
Additional:
URI: urn:oasis:names:tc:SAML:2.0:nameid-format:entity Indicates that
the content of the element is the identifier of an entity that
provides SAML-based services (such as a SAML authority) or is a
participant in SAML profiles (such as a service provider supporting
the browser SSO profiles). Such an identifier can be used in the
element to identify the issuer of a SAML request, response,
or assertion, or within the element to make assertions about
system entities that can issue SAML requests, responses, and
assertions. It can also be used in other elements and attributes whose
purpose is to identify a system entity in various protocol exchanges.
The syntax of such an identifier is a URI of not more than 1024
characters in length. It is RECOMMENDED that a system entity use a URL
containing its own domain name to identify itself
(SAML CORE specification, section 8.3.6)
https://www.oasis-open.org/committees/download.php/7473/sstc-saml-core-2.0-draft-15-diff.pdf
https://spaces.at.internet2.edu/display/InCFederation/Entity+IDs
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.
I implement a SAML 2.0 SP.
I have a login servlet with endpoint https://my.domain.com/mng/samlLogin, so in the SP metadata file I define:
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://my.domain.com/mng/samlLogin" index="0" isDefault="true"/>
And send this endpoint in the AuthenRequest under the AssertionConsumerServiceURL.
Now, I have another servlet with a different functionality, and it needs to validate the user against SAML as part of its flow.
So I need to define the new servlet's URL as an additional endpoint, let's say https://my.domain.com/mng/myServletSamlLogin , which will get SAML authentication reponse.
Is this possible? Can I define multiple AssertionConsumerService elements for the same binding (HTTP-POST)?
Thanks!
Yes, you can include additional <md:AssertionConsumerService> elements in the SAML 2.0 SP metadata with the same binding, each with its own unique index. Alternatively you can choose to sign the authentication requests as the SP in which case you can freely specify an AssertionConsumerServiceURL without the requirement that it was published and configured earlier as part of the SP metadata exchange.
This is all spec compliant but be aware (as always with "advanced" SAML options) that your mileage may vary wrt. support across different SAML implementations.
Have a look at Assertion Consumer Service Glossary which will tell you that
Assertion Consumer Service
A SAML-compliant portion of PingFederate in an SP role that receives
and processes assertions from an IdP.
attributes
Distinct characteristics that describe a subject. If the subject is a
Web site user, attributes may include a name, group affiliation, email
address, etc.
attribute contract
A list of attributes, agreed to by the partners in an identity
federation, representing information about a user (SAML subject). The
attributes are sent from the IdP to the SP during SSO or STS
processing.
So you associate bindings to the Assertion Consumer Service (ACS) endpoint(s) where your SP will receive assertions.
I was looking at some SAML 2.0 service provider metadata examples and came across a metadata file that had multiple NameIDFormat tags. Now most other examples I saw had just one so does this snippet indicate that the SP would accept NameID in SAML 1.1 as well as SAML 2.0 formats and can accept transient as well as persistent nameIDs in case of SAML 2.0 responses?
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>
Just so that others who are looking for an answer to this question know - I was able to confirm that my understanding is correct. SP can advertise support for multiple NameID formats that it can support using multiple tags in the SP metadata. However, its upto the IdP to honor this and send the NameID in one of the supported formats or completely ignore it and send it in a format not supported by the SP. In that case however the SP will not be able to parse the NameID value and will fail.