SimpleSAMLphp - Okta Integration

[Rich Horne]

Hey everyone! I hope you're all doing well. I came across this forum while searching for some assistance. 

I'm currently facing a situation where our client uses SimpleSAMLphp as an IDP, while our organization relies on Okta as an SP. However, there's a slight hiccup: Okta requires the Subject NameID to be in email format.

After configuring both applications and conducting an SSO test, we discovered that the client was passing the <saml:NameID> in a URN format, while the email was explicitly being provided in the <saml:AttributeStatement>. 

The admin shared this snippet:

<saml:Subject>
    <saml:NameID SPNameQualifier=https://www.okta.com/saml2/service-provider/##### Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">1234567</saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2024-04-25T09:42:46Z" Recipient=https://#####/sso/saml2/InResponseTo="########"/>
    </saml:SubjectConfirmation>
</saml:Subject>

 Just to clarify, do you need the `<saml:NameID>` to contain an email address? I've never encountered this requirement before, and I'm unsure how to proceed with passing the email address there. Typically, we pass user-specific details through attributes, as shown in the snippet below:

<saml:AttributeStatement>
    <saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue xsi:type="xs:string">########</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="firstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue xsi:type="xs:string">####</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="lastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue xsi:type="xs:string">Meehan</saml:AttributeValue>
    </saml:Attribute>
</saml:AttributeStatement>

Any insights on how to handle this would be greatly appreciated!

Kind regards

[Peter Schober]

Rich Horne <richho...@gmail.com> [2024-05-03 02:12 CEST]:

> Okta requires the Subject NameID to be in email format.

While that's an anti-pattern and violates saml2int.org (SDP-SP13) it's
possible to configuire SimpleSAMLphp to supply this.

> After configuring both applications and conducting an SSO test, we
> discovered that the client was passing the <saml:NameID> in a URN
> format,

All NameID formats the SAML specificication mentions (which you are
not limited to but see above for use/non-use of NameIDs these days)
have a formal name in URN format.
See SAML Core, section 8.3, Name Identifier Format Identifiers, e.g.:
https://groups.oasis-open.org/higherlogic/ws/public/download/56776/sstc-saml-core-errata-2.0-wd-07.pdf

> The admin shared this snippet:
>
> <saml:Subject>
> <saml:NameID
> SPNameQualifier=https://www.okta.com/saml2/service-provider/#####
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">1234567</saml:NameID>

So the IDP is sending a NameID format of "unspecified" (which is
another anti-pattern but at least it's not the SP here *specifically*
asking the IDP to send *specific* data as "unspecified" NameID) but
the SP wants this to be in that format:
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
(Note that *both* format identifiers are URIs/URNs.)

> Just to clarify, do you need the `<saml:NameID>` to contain an email
> address?

"You" do not (and the SAML specification certainly does not) and noone
should require such usage. But if Okta does what are you supposed to
do (other than to move away from broken services, which is always a
possibilty, I guess)?

> I've never encountered this requirement before, and I'm unsure how
> to proceed with passing the email address there. Typically, we pass
> user-specific details through attributes, as shown in the snippet below:

Sending data as attributes is how it should be -- modulo that you're
sending an invalid Attribute Name/NameFormat according to your example:

> <saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> <saml:AttributeValue xsi:type="xs:string">########</saml:AttributeValue>
> </saml:Attribute>

Here you're saying that "email" (the 'Name' of the attribute) is a URI
(according to the 'NameFormat'), which obviously is incorrect.
('urn:oasis:names:tc:SAML:2.0:attrname-format:basic' would be the
correct NameFormat if you insisted on sending 'email' as Name. But you
shouldn't be using that either because everyone will have differing
ideas what to name a common attribute, "email", "mail", "e-mail",
"eMail", etc. which is why the most interoperable and scalable way is
to keep the Attribute NameFormat as above and actually use formal URIs
are attribute *names*, following the SAML LDAP/X.500 Attribute Profile:
https://wiki.oasis-open.org/security/SstcSaml2AttributeX500Profile
SimpleSAMLphp provides "attribute map" feature to make sending those
easy.)

> Any insights on how to handle this would be greatly appreciated!

Use the saml:AttributeNameID authproc filter SSP provides for this:
https://simplesamlphp.org/docs/stable/saml/nameid.html
Forther down the document there's a full example for its use
("This example makes three NameIDs available", it's the 3rd one you
want.)

HTH,
-peter

[Rich Horne]

Hi Peter,

I appreciate your helpful insights and guidance. The links you provided are really informative and I'm eager to explore the topics further.

Thanks again for your contribution.

Best regards,
Rich