Re: [Unity-idm-discuss] Integrating remote IDP

[Krzysztof B. <kb...@un...>]

Hi D,

uff, a complex email :-)


Let's start from a small terminology clarification, to ensure we are on 
the same page.

In Unity there a certain situation which is called as "unknown remote 
user" flow. It is triggered when a user authenticates using external 
IdP, but after successful remote authentication, this user is not mapped 
(by means of input translation profile) onto _existing_ local entity. 
Example: user, after returning from external IdP, was mapped to 
'username' identity with value 'awst', but there is no 'awst' present in 
Unity's DB.

And now the remaining clarifications:

1. So in the "unknown remote user" flow you can either (a) put user into 
registration flow (which typically includes an interactive step of 
filling some form, but need not to) or (b) put user into account 
association flow where user has to link the unknown remote identity with 
some other existing locally account. So (b) is essentially when remote 
identity is auxiliary, an addition to a regular, mandatory local 
account. A rare case. Finally there is (c) - user can choose on her own 
whether to do (a) or (b). In practice (a) or (c) is used.

2. In order to trigger the "unknown remote user" flow, make sure _not to 
auto create_ a user using input profile. I.e. if you use in your profile 
mapIdentity action with CREATE_OR_MATCH, this flow will be never 
triggered, as profile will either match with the existing user or create 
a local account for the remote one and match to it. I guess this is your 
problem from "as a side note".

3. Unity has no feature to decide whether to start flow (a) or (b) or go 
to (c) at runtime. Which path is taken is a result of static 
configuration. I agree that we may have a feature here: we can allow 
admins to specify some rule to check whether there is a local user who 
looks _similar_ to the remote one, and basing on this similarity either 
suggest user identity linking, or skip it. However this is a very 
complex feature: similarity will be different between deployments, 
checking it may require full text searches with text distance metering 
support etc. Some will check by same email, some with name, some with 
pair of surname and first name, some will take into account institution 
etc. And even with all of this - what if the similarity check returns 
that there is no one similar, but user has a local account and wants to 
link with it?

4. Your particular case sounds for me as one example of the above: on 
one hand you want to ask user to link accounts if remote username 
matches local one. But on another you don't trust remote one. So can you 
guarantee that remote user "johnny" is not the same as previously 
registered local "j.smith"? I.e. there is not only a security precaution 
not to link automatically to take into account, but also a question why 
not to allow for linking when usernames do _not_ match.


OK, so what you can do with Unity is: ignore whether remote username is 
the same as the local one, just treat remote username as remote 
'identifier' typed identity, perhaps with some prefix as a namespace. 
Function of this identifier will be to match _returning_ remote users. 
Follow path (c), i.e. when unknown remote user flow is triggered (i.e. 
this will be when a given user logs into unity with remote identity for 
the very 1st time): allow the user to select whether to link account or 
register. If linking is chosen Unity will ask the user for 
authenticating with the local account (2nd authN for the user), after it 
accounts will be linked, login with either of them will be equivalent 
(well, subject to MFA settings, but typically). If user chooses to 
register then you can provide a registration form exactly as you 
envision: prefilled with remote data and also prompting for password setup.

Does it work for you? Also note that there are also other options, much 
different. E.g. you can create a registration form, using remote 
credential. So you can guide users to register using remote identity. 
This is more typical path, as you can instruct user more clearly what 
happens, is more often used then the "unknown remote user flow", in 
which users have to try to authenticate even when they don't have any 
account/haven't access your service yet. This may be puzzling for some, 
who will search for "sign up" instead of trying to "sign in".

Other option is to remove account linking from the flow, if this is a 
rare choice, and rather treat it as special case: two accounts can be 
also associated outside of login flow.

I hope I clarified this at least a little bit, not other way round :-)

Best,
Krzysztof