I need to use a custom NameID format for one client that is using my IDP.
I can edit saml-nameid.xml to use an attribute in NameID and this works fine however it affects everyone that is using format urn:oasis:names:tc:SAML:2.0:nameid-format:transient.
I know it is possible to have 2 NameID Generators associated with the format but it seems to just pick the first one as registered in saml-nameid.xml
How do I go about choosing between them based on which SP is calling my IDP.
Note I am using IDP version 3
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).
I've set up Shibboleth IDPv3 to test my SP implementation. SP sends a SAML Logon request and the user is presented with the Shibboleth IDP credentials page in which the user enters their Kerberos credentials (I've configured the Loginflow with KerberosAuthNConfiguration). The SAML response comes back with a nameId which has what looks like an encoded value. However, what I want is the NameId element to contain the username that the user used to login to the IDP credentials page.
I had a few attempts by trying to configure the beans in the various XML configuration files without any luck. Has anybody tried something similar is this even possible to achieve ?
If you look in the file saml-nameid.properties you will see the parameter idp.nameid.saml2.default. I suspect that your configuration is set to the default of urn:oasis:names:tc:SAML:2.0:nameid-format:transient which is not an encoded value, but rather a random string.
It sounds like you want to send a "persistent" identifier rather than a transient identifier. To do this,
Change idp.nameid.saml2.default to urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.
Next, you will need to enable the Persistent NameID Generator in the file saml-nameid.xml.
Finally you need to set the attribute to use in your nameid via the idp.persistentId.sourceAttribute property, also in saml-nameid.properties.
Details on how to do this can be found at the Shibboleth IdP PersistentNameIDGenerationConfiguration page.
I am writing a SAML SP and can not figure out a uniform way to extract a user's username/login from the SAML response returned by the IdP. It looks like this information can be in a variety of places (NameID, Attribute) from different IdP's, and the IdP metadata does not seem to offer any hints.
Right now, I am using an extra configuration directive containing XPath for retrieving the username, but would like to eliminate this. Is this something I can specify in SP metadata?
It's unrelated to SAML Meta Data, but a proprietary configuration of your SP.
As you stated, you could either use the value of the NamedID or the value of an Attribute Statement. If your SP allows to do SSO with different IdPs this setting could be IdP-entity based. E.g. one IdP may only support the 'transient NameId Format' then you can not use the value as it's an opaque handle which must change all the time. To get some idea you may look at OpenAM's doc, it is using an 'Account Mapper' for this purpose (https://backstage.forgerock.com/docs/openam/13.5/admin-guide/chap-federation#sp-account-mapper)
I have many clients that uses SSO, for that we use SAML 2. Many of my clients uses providers like Okta, PingIdentity and a bunch of them ADFS. Doing the integration with ADFS always at the beginning raises this error when they came back with the SAMLResponse.
<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester"><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></samlp:StatusCode></samlp:Status>
Im asking to use as name Identifier this:
"urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
Im pretty new to SAML and I just want to know what is happening on ADFS, since this is just happening with clients that uses that.
Thanks a lot.
By default, ADFS sends the NameId format as "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified". You can adjust it. See: https://social.technet.microsoft.com/wiki/contents/articles/4038.ad-fs-2-0-how-to-request-a-specific-name-id-format-from-a-claims-provider-cp-during-saml-2-0-single-sign-on-sso.aspx
The other way to do this is to identity what attribute needs to be mapped to NameID e.g. email address.
Have a normal LDAP rule for email.
Then have a Transform rule that transforms email to NameID and select the NameID format you need from the drop-down.
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.