Issue with username value when No Account exists

[ehuibers]

We are encountering an issue when no account exists in the user store.

In that case the next call is made by SAML2Node.java to update the sharedstate:
// If it wasn't then setup attributes and go to No Account outcome.
return setSessionProperties(
Action.goTo(AbstractSocialAuthLoginNode.SocialAuthOutcome.NO_ACCOUNT.name())
.replaceSharedState(
setupAttributes(
spssoConfig,
decryptionKeys,
nameId,
spName,
sharedState,
dn,
persistNameId,
needAssertionEncrypted
)
),
nameId
);

AFAICS the dn attribute is empty in this case. As the dn is used by the setupAttributes function to set the usernames key in the sharedstate, we end up with a sharedstate with no usernames key.
This is also shown in the Authentication debug logging when set to the message level.

The next node in the tree (Provision Dynamic Account) then generates a GUID and uses that as the username to create the user profile.

This blocks us from using the SAML2 Node in a tree at this moment.

Note: when using an authentication chain with a SAML2 module using the same remote IdP and hosted SP, the dynamic profile is created succesfully and the NameID value is used as the username.

[FrankGasparovic]

Hi Eddie,
The way the logic works is that if the dn isn't present (user doesn't exist in the data store), the NameID is set in sharedState as the Username. Also, the Provision Dynamic Account No will throw an exception if there is no Username in sharedState.

What might be happening is the GUID you are seeing is being sent over by the IdP as the NameID, so the SAML node is setting that GUID in sharedState.

[aldaris]

There are two problems in play here:

1. The SP account mapper contract doesn't really enforce that the returned user ID is actually in the universal ID format, hence it is possible that in case of dynamic provisioning, the account ID is just the plain user name, and not the complete universal ID as one would hope. (In 7.0.0 we try to work this inconsistency around by updating SPACSUtils to convert non-universal ID user IDs to universal IDs..)
2. Even when the user ID is in the correct format, the shared state is not quite correct. The USER_NAMES_SHARED_STATE_KEY map only contains username=username mapping, but the dynamic account provisioning node looks for a hardcoded "uid" attribute in that map instead. (in 7.0.0 we'll add the UID to that map next to the USERNAME mapping).

[FrankGasparovic]

Ah, understood, thanks for the clarification Peter. It looks like in my configuration, I am am mapping an attribute from the IdP to SP for "uid".

When I remove that mapping, I am seeing the same behavior that @ehuibers described above (randomly generated uid).

@ehuibers - Can you please try and map an attribute to UID in your SP configuration?

[ehuibers]

Thanks for your help in this.

@FrankGasparovic it looks like in your case the SAML2 token sent by IdP contains a SAML attribute uid which you map to the uid attribute. When I test using my own IdP I have the same experience.

But... in my case the IdP we are using is a remote IdP (government controlled) which only gives us a NameID in the SAML2 token. There are no SAML attributes which we can use as a source attribute for the uid.

[ehuibers]

I did some more digging in the debug logging and I can see the following regarding the SharedState.

amAuth:12/05/2019 07:56:33:462 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
newSharedState
{realm=/,
authLevel=0,
userGotoParam=/auth/SSORedirect/metaAlias/idp?ReqID=_6f1d2463d4866dc7673d15582db056f8880a0a03e2&index=null&acsURL=https://appserver.company.com/simplesaml/module.php/saml/sp/saml2-acs.php/SimpleSAML&spEntityID=SimpleSAML&binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST,
userInfo={
attributes={
mail=[eddie.huibers@company.com],
givenName=[Eddie],
sn=[Huibers],
cn=[Huibers, Eddie (CIV)],
sun-fm-saml2-nameid-info=[https://acc.fam.company.com:443/auth|https://acceptatie.federatie.company.com/adfs/services/trust|eddie.huibers@company.com|https://acceptatie.federatie.company.com/adfs/services/trust|urn:oasis:names:tc:SAML:2.0:nameid-format:persistent|null|https://acc.fam.company.com:443/auth|SPRole|false],
sun-fm-saml2-nameid-infokey=[https://acc.fam.company.com:443/auth|https://acceptatie.federatie.company.com/adfs/services/trust|eddie.huibers@company.com]},
userNames={username=[eddie.huibers@company.com]}
},
emailAddress=eddie.huibers@company.com}

Question: shouldn't this newSharedState contain a username=eddie.huibers@company.com entry which is at the same level as the emailAddress key?

Going further in the debug log I see:
amAuth:12/05/2019 07:56:33:462 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
newSessionProperties {openam.saml.singlelogout.enabled=false, metaAlias=/sp, cacheKey=784af826-57b1-469f-a143-1fc70fcbf5c0, NameID=<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NameQualifier="https://acceptatie.federatie.company.com/adfs/services/trust" SPNameQualifier="https://acc.fam.company.com:443/auth" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">eddie.huibers@company.com</saml:NameID>, spEntityID=https://acc.fam.company.com:443/auth, requestId=s2b9e3267a6fa6f681852adf6735937cc0f1e367d3, SessionIndex=_e63a374b-4788-4cea-b3b6-ac13eb5da8d2, reqBinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect, binding=HTTP-POST, isTransient=false, idpEntityID=https://acceptatie.federatie.company.com/adfs/services/trust}

amAuth:12/05/2019 07:56:33:463 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
continue processing the tree

amAuth:12/05/2019 07:56:33:463 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
nextNodeId 7dfeb985-94c2-4a56-8a31-395db4c43209

amAuth:12/05/2019 07:56:33:463 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
nodeType ProvisionDynamicAccountNode

amAuth:12/05/2019 07:56:33:553 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
realm /
tree proxy
amAuth:12/05/2019 07:56:33:553 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
ProvisionAccount node started

amAuth:12/05/2019 07:56:33:594 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
User created: 01def161-4c43-4cd6-90eb-72bd6f00a6db

amAuth:12/05/2019 07:56:33:594 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
newSharedState
{realm=/,
authLevel=0, userGotoParam=/auth/SSORedirect/metaAlias/idp?ReqID=_6f1d2463d4866dc7673d15582db056f8880a0a03e2&index=null&acsURL=https://appserver.company.com/simplesaml/module.php/saml/sp/saml2-acs.php/SimpleSAML&spEntityID=SimpleSAML&binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST,
userInfo={
attributes={
mail=[eddie.huibers@company.com],
givenName=[Eddie],
sn=[Huibers],
cn=[Huibers, Eddie (CIV)], sun-fm-saml2-nameid-info=[https://acc.fam.company.com:443/auth|https://acceptatie.federatie.company.com/adfs/services/trust|eddie.huibers@company.com|https://acceptatie.federatie.company.com/adfs/services/trust|urn:oasis:names:tc:SAML:2.0:nameid-format:persistent|null|https://acc.fam.company.com:443/auth|SPRole|false],
sun-fm-saml2-nameid-infokey=[https://acc.fam.company.com:443/auth|https://acceptatie.federatie.company.com/adfs/services/trust|eddie.huibers@company.com]},
userNames={username=[eddie.huibers@company.com]}
},
emailAddress=eddie.huibers@company.com,
username=01def161-4c43-4cd6-90eb-72bd6f00a6db
}
amAuth:12/05/2019 07:56:33:594 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
newSessionProperties {openam.saml.singlelogout.enabled=false, metaAlias=/sp, cacheKey=784af826-57b1-469f-a143-1fc70fcbf5c0, NameID=<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" NameQualifier="https://acceptatie.federatie.company.com/adfs/services/trust" SPNameQualifier="https://acc.fam.company.com:443/auth" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">eddie.huibers@company.com</saml:NameID>, spEntityID=https://acc.fam.company.com:443/auth, requestId=s2b9e3267a6fa6f681852adf6735937cc0f1e367d3, SessionIndex=_e63a374b-4788-4cea-b3b6-ac13eb5da8d2, reqBinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect, binding=HTTP-POST, isTransient=false, idpEntityID=https://acceptatie.federatie.company.com/adfs/services/trust}

amAuth:12/05/2019 07:56:33:594 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
Success or failure result - outcome TRUE

amAuth:12/05/2019 07:56:33:594 AM CET: Thread[https-openssl-nio-443-exec-2,5,main]: TransactionId[15aa635f-91c4-4233-8daa-64579e7feae6-4048]
treeResult after process: callbacks []
outcome TRUE
sharedState
{ "realm": "/",
"authLevel": 0,
"userGotoParam": "/auth/SSORedirect/metaAlias/idp?ReqID=_6f1d2463d4866dc7673d15582db056f8880a0a03e2&index=null&acsURL=https://appserver.company.com/simplesaml/module.php/saml/sp/saml2-acs.php/SimpleSAML&spEntityID=SimpleSAML&binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
"userInfo": {
"attributes": {
"mail": [ "eddie.huibers@company.com" ],
"givenName": [ "Eddie" ],
"sn": [ "Huibers" ],
"cn": [ "Huibers, Eddie (CIV)" ],
"sun-fm-saml2-nameid-info": [ "https://acc.fam.company.com:443/auth|https://acceptatie.federatie.company.com/adfs/services/trust|eddie.huibers@company.com|https://acceptatie.federatie.company.com/adfs/services/trust|urn:oasis:names:tc:SAML:2.0:nameid-format:persistent|null|https://acc.fam.company.com:443/auth|SPRole|false" ],
"sun-fm-saml2-nameid-infokey": [ "https://acc.fam.company.com:443/auth|https://acceptatie.federatie.company.com/adfs/services/trust|eddie.huibers@company.com" ] },
"userNames": {
"username": [ "eddie.huibers@company.com" ] }
},
"emailAddress": "eddie.huibers@company.com",
"username": "01def161-4c43-4cd6-90eb-72bd6f00a6db" }

[aldaris]

After talking with Frank, I'm slowly realising that this use-case is still not completely resolved in 7.0.0 either. It seems like that the Provision Dynamic Account node is just not flexible enough to implement this exact use-case. I've raised an RFE for AM:
https://bugster.forgerock.org/jira/browse/OPENAM-15759

The gist of the problem is that the user ID determined by the account mapper is not part of the userInfo/attributes object by default. We could squeeze it in, but not sure under what key then (and the default account provider still hardcodes getting the "uid" attribute out of it). The other side of the problem is that if there is a need for a local authentication (because the user ID could not be determined by the account mapper), then that local authentication would need to update the userInfo/attributes object with the new user name, which could get slightly awkward.
The current workaround is to write a custom SP attribute mapper that would put the userID argument under the uid attribute in the returned attribute map. This will work when the account mapper can determine the user ID, but it will not work otherwise.