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

[D B. <ba...@aw...>]

Hi!

First of all: thanks for taking the time to answer these detailed
questions, I really appreciate it!

On 21/04/2020 23:12, Krzysztof Benedyczak wrote:
> 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.

It sounds like (c) would be the most useful in my case, so let's go with
that.

> 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".

OK, so now I've got this in my input translation profile:
mapIdentity
unityIdentityType: identifier
expression: 'remote-' + attr['username']
credential requirement: Password requirement
effect: UPDATE_OR_MATCH

In my remote SAML facility config, I've selected the external
registration form I've created and disabled account association. The
registration form collects identities 'identifier' 'From remote IdP and
shown RO' and 'userName' from user input (so hopefully a user can chose
a local username on registration).

I still never get to see the registration dialog. In the logs, unity
complains:
unity.server.externaltranslation.InputTranslationEngineImpl: Identity
MappedIdentity [mode=UPDATE_OR_MATCH, identity=[identifier]
remote-dbaum, credentialRequirement=Password requirement] not found in
DB, details of exception follows
pl.edu.icm.unity.exceptions.UnknownIdentityException: Entity
[identifier] remote-dbaum is unknown

On the GUI, unity complains:
The remote authentication was successful, however your identity is not
accepted by the local service. Please contact administrators or try to
register first.

Pretty much the same thing happens for mode=MATCH.

What do I need to do to put users into the remote registration flow? I'm
guessing my input translation profile isn't doing the right thing?

> 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.


Nah, I agree, it doesn't need to be that complicated in unity.
1) I don't mind if they have different remote and local usernames - as
long as the local username is always the one propagated to unity's clients.
2) Users who want their pre-existing local and remote accounts linked
can be expected to manually trigger the association process. Users who
don't have a pre-existing local account should be presented with a
registration form.

Also, automatically guessing which remote user corresponds to a local
user sounds like a security nightmare.

> 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.

Cool! But... how do I do that? I've tried using a remote identifier
identity but can't get to the registration form or to the account
association (see above).

>  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? 

That would work for me, but currently it doesn't yet work in my setup ;-)

> 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".

So the difference is what? You get all remote users to register and
afterwards they can manually associate their remote and local accounts?

Cheers,
D