OpenAM hosted SP (SP initiated) missing attributes

Setup
, , , , , , ,
#1

Hi there,
I made an hosted SP and a remote IDP to use an Openam SP initiated session, calling to an external IDP.
I’d like to pass to the IDP the NameID into the AuthnRequest.
But the SAML message sent back to the IDP actually doesn’t have that attribute.
How can I add the name id attribute to the request?

#2

Hi @pierluigiconti80

I’m assuming you are referring to the NameIDPolicy element in the AuthnRequest, is that correct? If so, I’m surprised to see that you are not observing that element in the AuthnRequest. Can you confirm how you are initiating the authentication request, and if possible share an example of the SAML AuthnRequest?

#3

Hi mwtech,
first of all thank you a lot for your answer.
To be more exact I am referring to the NameID attribute, something like this:
<saml:Subject xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>
saml:NameIDpierluigi</saml:NameID>
</saml:Subject>

That’s why I am trying to make this scenario:

  1. User logs in into OpenAM as IDP (OpenAM does the authentication process through Active Directory)
  2. OpenAM then acts as an SP for another external IDP (which does only MFA: it’s just an MFA provider), passing to it the SAML subject (which is the username the user has prompted in)
  3. the user is then redirected to the external IDP, does the MFA and is redirected back to OpenAM.
  4. the authentication has be done
#4

Ah! This is a bit more complex, and I’d need to think this one over as I can’t say I’ve encountered this particular pattern before. The challenge here is that an SP is not intended to know what the NameID is that the IDP will pass back - part of why the SP contacts the IDP is that it wants to know not only that the user has authenticated, but who the user is. In the SAML world the IDP typically (in my experience, always) handles the generation of the NameID. A quick glance at the SAML XSD (https://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd) tells me that including a NameID in an AuthnRequest is not valid, although it has (thankfully) been a while since I’ve had to translate an XSD.

Not to sidetrack too far from your original question, but is there a reason for AM (as the IDP) to not integrate directly with this external IDP to perform the MFA? To me that feels like the best approach here since it not only breaks you out of this SAML anti-pattern (if it is indeed even feasible) but it also helps give AM the context of what level of authentication has actually taken place which can help you with authorization decisions.

#5

so you mean to write a specific module in order to integrate the AM and the external MFA provider?

#6

Hopefully it would be a node (Authentication Tree) and not a module (Authentication Chain), but whichever of those suits your needs would be the ideal route if possible. As always there are likely a lot more factors in play than what have been discussed here, but if you are able to consolidate your authentication into a single system it simplifies the flow considerably and allows AM to remain an authoritative source for what authentication factors have been used to authenticate a user to your system.