unity-idm-discuss — Unity discussion and support

Re: [Unity-idm-discuss] Prevent users from registering existing usernames

[Marcus H. <ha...@ki...>]

Sorry for chipping in on this late and with a totally different
background.

Disclaimer:
I'm running only OIDC clients.

We receive the username as "preferred_username". This preference is taken
into account, but modified according to requirements that we have.  One of
these requirements is (of course) that the username is unique.

In other words: It be nice, if unity could take care of this, but in the
end I would not blindly create users with names from an external
datasource.

My five cent.

M.



On 04/27/20 21:18, D Baum wrote:
> Hi,
> 
> just found out that I can prevent duplicate userNames in unity by
> editing the attribute type 'userName' and checking 'Unique values'.
> This will prevent moderators from activating accounts with duplicate
> usernames. However, it doesn't prevent users from registering accounts
> with already existing usernames. (I guess that such a feature might be
> used to bruteforce existing usernames.)
> 
> The workflow for registrations is pretty awkward in this case. As far as
> I understand, the moderator can't edit the request (and change the
> username) and the user has no way of knowing if the username already
> exists. So I guess the mod has to deny the request and manually write to
> the user 'Hey, username suchandsuch is already taken, please pick
> another one' and the user has to register again. Or the admin has to
> manually create the user and copy all attributes.
> 
> Is there a better way to handle this?
> 
> Cheers,
> D
> 
> 
> _______________________________________________
> Unity-idm-discuss mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss
> 

-- 
Marcus.

Re: [Unity-idm-discuss] Revoke Tokens from oauth2 authenticator Unity

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

Hi Tim,

W dniu 12.05.2020 o 11:26, Tim Kreuzer pisze:
> Hey,
>
> we're using one webservice and two Unitys. One Unity is configured as
> oauth2 authenticator for the other.
>
> Configuration for the <second_unity> (<first_unity_conf>:
> unityServer.core.authenticators.hdfaai.configurationFile):
> ---
> unity.oauth2.client.providers.hbp.type=unity
> unity.oauth2.client.providers.hbp.clientId=...
> unity.oauth2.client.providers.hbp.clientSecret=...
> unity.oauth2.client.providers.hbp.openIdConnect=true
> unity.oauth2.client.providers.hbp.httpClientHostnameChecking=WARN
> unity.oauth2.client.providers.hbp.httpClientTruststore=MAIN
> unity.oauth2.client.providers.hbp.name=Helmholtz
> unity.oauth2.client.providers.hbp.openIdConnectDiscoveryEndpoint=
> https://<second_unity>/oauth2/.well-known/openid-configuration
> unity.oauth2.client.providers.hbp.scopes=email openid display_name
> single-logout
> unity.oauth2.client.providers.hbp.translationProfile=tr-hdfaai-input
> ---
>
> If a user logs into my webservice and uses the <second_unity> as
> authenticator I will receive an accesstoken/refreshtoken at my
> webservice. I'm able to revoke these tokens when the user logs out.
>
> But additionally two tokens are generated at the <second_unity>. Is
> there a way to let the <first_unity> revoke these tokens? So that all 4
> tokens, generated for this user (two on each Unity), will be revoked?
>
>
> The Request I make to revoke the tokens is:
>
> POST https://<first_unity_oauth_endpoint>/revoke
> Headers:
> {
>    'Content-Type': 'application/x-www-form-urlencoded'
> }
> Body:
> {
>    'client_id': '...',
>    'logout': 'true',
>    'token_type_hint': 'refresh_token', # or access_token
>    'token': '...'
> }
>
>
>
> If that's not possible: Is there a way to receive the tokens from the
> <second_unity>? So that I can revoke them separately?

Not really :/

What you are asking about it SLO for OAuth. There are defined protocols 
to achieve this (I'm aware of three...) all in draft state. This is 
because typically OAuth is used by social identity providers, and when 
logging out from your app, you shouldn't be logged out from Google/FB/MS 
or any other of those providers fully not realted to the app. You can 
achieve such behavior with full Unity support when using SAML.

Still, we heard this already once and I think we had this issue with one 
setup internally. I'll open a ticket to evaluate the current state of 
the drafts and see if we can have one of them implemented. Still this 
will work only in cases when you have a compatible provider - maybe even 
only in unity <-> unity setup.


Cheers,
Krzysztof

Re: [Unity-idm-discuss] Prevent users from registering existing usernames

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

Hi,

W dniu 06.05.2020 o 11:04, D Baum pisze:
> Hi,
>
> On 30/04/2020 22:25, Krzysztof Benedyczak wrote:
>>> just found out that I can prevent duplicate userNames in unity by
>>> editing the attribute type 'userName' and checking 'Unique values'.
>>> This will prevent moderators from activating accounts with duplicate
>>> usernames.
>> Up to this point I don't quite understand. If you want to register users
>> and assign them unique 'userName' why you don't use identity? Either of
>> userName type or identifier type? All identities are guaranteed to be
>> unique.
> I think I do, at least as far as I can tell (users are listed in the
> directory with 'identity type' 'userName').

OK

> But I still observe that you can register a new entity with an existing
> username - the moderator just can't accept the registration. So the
> security issue is averted but it's a bit inconvenient.

Yes, that is clear. And as I wrote previously we can implement a 
registration feature to prevent accepting registration requests using 
already occupied identity.

> Also, iirc, before I edited the username attribute type to be unique, I
> could even accept the duplicated username entities.

So 'username attribute type' is a totally different story, not related 
to identities. You have a 'username attribute type' then you can assign 
it to any user, it is group scoped (so that one user can have different 
values in differnet groups). And the setting to make the values unique 
is only used for multivalued attributes. You can enforce that the same 
value is not used many times for such attribute.

So if you put user name into an attribute then you will be able to 
register a many users with the same user names.

> Maybe I'm missing special behaviour of the "confirmation mode" in the
> registration form definition? Currently, the userNames in my form are
> "Confirmed, without verification".

Confirmation mode is used for some attributes only, like email, and 
governs how their confirmation by the user should be triggered.

We should improve UI to disable this control on attribute types which do 
not support confirmation.

>> Well, I don't think so. We can't just by default check registration
>> request whether identities are free (and same about attributes which are
>> there) due to what you pointed out, and also as automation of
>> registration form may change entered values.
>>
>> But surely this sounds as an easy to do and sensible feature as a
>> configurable option of a form. I.e. that form can be configured
>> explicitly by admin so that at submission identities should be checked
>> is are available. (*)
>>
>> Note of course that this won't be 100% accurate: if you have
>> non-automatic acceptance a free identity at form submission time may
>> become occupied before it is accepted. Reserving identities for pending
>> requests would be much more challenging task.
>>
>> So what do you think about (*)?
> Sounds very nice to me, I'd be happy to use that feature if it gets
> implemented :-)
>
OK, I'll open a ticket. Should be easy, but we need to think where to 
put configuration of such feature.

Thanks,
KB

[Unity-idm-discuss] Revoke Tokens from oauth2 authenticator Unity

[Tim K. <t.k...@fz...>]

Hey,

we're using one webservice and two Unitys. One Unity is configured as
oauth2 authenticator for the other.

Configuration for the <second_unity> (<first_unity_conf>:
unityServer.core.authenticators.hdfaai.configurationFile):
---
unity.oauth2.client.providers.hbp.type=unity
unity.oauth2.client.providers.hbp.clientId=...
unity.oauth2.client.providers.hbp.clientSecret=...
unity.oauth2.client.providers.hbp.openIdConnect=true
unity.oauth2.client.providers.hbp.httpClientHostnameChecking=WARN
unity.oauth2.client.providers.hbp.httpClientTruststore=MAIN
unity.oauth2.client.providers.hbp.name=Helmholtz
unity.oauth2.client.providers.hbp.openIdConnectDiscoveryEndpoint=
https://<second_unity>/oauth2/.well-known/openid-configuration
unity.oauth2.client.providers.hbp.scopes=email openid display_name
single-logout
unity.oauth2.client.providers.hbp.translationProfile=tr-hdfaai-input
---

If a user logs into my webservice and uses the <second_unity> as
authenticator I will receive an accesstoken/refreshtoken at my
webservice. I'm able to revoke these tokens when the user logs out. 

But additionally two tokens are generated at the <second_unity>. Is
there a way to let the <first_unity> revoke these tokens? So that all 4
tokens, generated for this user (two on each Unity), will be revoked?


The Request I make to revoke the tokens is:

POST https://<first_unity_oauth_endpoint>/revoke
Headers: 
{
  'Content-Type': 'application/x-www-form-urlencoded'
}
Body:
{
  'client_id': '...',
  'logout': 'true',
  'token_type_hint': 'refresh_token', # or access_token
  'token': '...'
}



If that's not possible: Is there a way to receive the tokens from the
<second_unity>? So that I can revoke them separately?


Best regards, 
Tim Kreuzer


-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 1583
email: t.k...@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

[Unity-idm-discuss] Changed behaviour of translation profile configuration

[Sander A. <sa....@fz...>]

Dear Krzysztof,

we updated last week from unity 2.8.2 to unity 3.2.2. After this update
we got an issue with one of our connected IdPs.

We had, which was an error on our site, configured the authenticator to
used the translation profile "marineID" but created the translation
profile "MarineID" within unity GUI. This mismatch worked fine until
unity 2.8.2. and it seems that this configuration was case-insensitive.

After the update we got an ticket that the login is not working and we
started to investigate. After the error about unknown translation
profile "marineID" we found the problem quite fast and changed the
configuration from "marineID" into "MarineID" and reloaded the
authenticator. Sadly the problem and error message kept the same and we
decided to restart unity (load config from files instead of database)
but the problem and error was still the same.

Only changing the configuration and translation profile into "marineID"
solved the issue. Because renaming a translation profile in the GUI
(does not yes exists as file) and having two files with the same name
(one starting with a capital, one with a lower letter) is not possible
we had to copy the old one, remove it, and copy the copy to the old one
with lower name.

Was it intended to make the translation profile matching between
configuration and existing profiles case sensitive? Was it intended
that the translation profiles need to start with a small letter?

In case both was intended can you please update the documentation to
hint to that fact that translation profiles must start with lower
letters and can you highlight such changes where you switch from
(probably unwanted) case-insensitive to case-sensitiv configurations? 

Best regards,
Sander
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] prohibiting login in home endpoint with oauth client credentials

[Sander A. <sa....@fz...>]

Hi Krzysztof,

there was another issue with the password. After this was solved, the
authorisation code flow works too.

Best regards,
Sander

On Thu, 2020-05-07 at 11:26 +0200, Sander Apweiler wrote:
> Hi Krzysztof,
> 
> sorry for not responding earlier but there were some other issues.
> 
> The anonymous users prohibits the login as wanted, but the
> authorization code flow does not work too.
> 
> Best regards,
> Sander
> 
> On Sat, 2020-03-28 at 23:16 +0100, Krzysztof Benedyczak wrote:
> > Hi Sander,
> > 
> > W dniu 14.03.2020 o 10:30, Krzysztof Benedyczak pisze:
> > > Hi Sander,
> > > 
> > > W dniu 11.03.2020 o 12:05, Sander Apweiler pisze:
> > > > Hi Krzysztof,
> > > > 
> > > > this is still an issue for us and users asked for some updates.
> > > > How is
> > > > your plan with the RO-user?
> > 
> > Good news, I was completely wrong here. When I tried to check how 
> > difficult it is to implement, I've discovered that... this feature
> > is 
> > available. Just set the "Anonymous user" role to your oauth client.
> > It 
> > is exactly what you need: a fully read only user, who can not
> > modify 
> > even its own credential.
> > 
> > We should change the name of this role to "Read only user"
> > eventually...
> > 
> > Cheers,
> > Krzysztof
> > 
> > 
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] prohibiting login in home endpoint with oauth client credentials

[Sander A. <sa....@fz...>]

Hi Krzysztof,

sorry for not responding earlier but there were some other issues.

The anonymous users prohibits the login as wanted, but the
authorization code flow does not work too.

Best regards,
Sander

On Sat, 2020-03-28 at 23:16 +0100, Krzysztof Benedyczak wrote:
> Hi Sander,
> 
> W dniu 14.03.2020 o 10:30, Krzysztof Benedyczak pisze:
> > Hi Sander,
> > 
> > W dniu 11.03.2020 o 12:05, Sander Apweiler pisze:
> > > Hi Krzysztof,
> > > 
> > > this is still an issue for us and users asked for some updates.
> > > How is
> > > your plan with the RO-user?
> 
> Good news, I was completely wrong here. When I tried to check how 
> difficult it is to implement, I've discovered that... this feature
> is 
> available. Just set the "Anonymous user" role to your oauth client.
> It 
> is exactly what you need: a fully read only user, who can not modify 
> even its own credential.
> 
> We should change the name of this role to "Read only user"
> eventually...
> 
> Cheers,
> Krzysztof
> 
> 
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Prevent users from registering existing usernames

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

Hi,

On 30/04/2020 22:25, Krzysztof Benedyczak wrote:
>> just found out that I can prevent duplicate userNames in unity by
>> editing the attribute type 'userName' and checking 'Unique values'.
>> This will prevent moderators from activating accounts with duplicate
>> usernames.
> 
> Up to this point I don't quite understand. If you want to register users
> and assign them unique 'userName' why you don't use identity? Either of
> userName type or identifier type? All identities are guaranteed to be
> unique.

I think I do, at least as far as I can tell (users are listed in the
directory with 'identity type' 'userName').
But I still observe that you can register a new entity with an existing
username - the moderator just can't accept the registration. So the
security issue is averted but it's a bit inconvenient.
Also, iirc, before I edited the username attribute type to be unique, I
could even accept the duplicated username entities.

Maybe I'm missing special behaviour of the "confirmation mode" in the
registration form definition? Currently, the userNames in my form are
"Confirmed, without verification".

> Well, I don't think so. We can't just by default check registration
> request whether identities are free (and same about attributes which are
> there) due to what you pointed out, and also as automation of
> registration form may change entered values.
> 
> But surely this sounds as an easy to do and sensible feature as a
> configurable option of a form. I.e. that form can be configured
> explicitly by admin so that at submission identities should be checked
> is are available. (*)
> 
> Note of course that this won't be 100% accurate: if you have
> non-automatic acceptance a free identity at form submission time may
> become occupied before it is accepted. Reserving identities for pending
> requests would be much more challenging task.
> 
> So what do you think about (*)?

Sounds very nice to me, I'd be happy to use that feature if it gets
implemented :-)

Cheers,
D.

Re: [Unity-idm-discuss] Prevent users from registering existing usernames

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

Hi,

W dniu 27.04.2020 o 21:18, D Baum pisze:
> Hi,
>
> just found out that I can prevent duplicate userNames in unity by
> editing the attribute type 'userName' and checking 'Unique values'.
> This will prevent moderators from activating accounts with duplicate
> usernames.

Up to this point I don't quite understand. If you want to register users 
and assign them unique 'userName' why you don't use identity? Either of 
userName type or identifier type? All identities are guaranteed to be 
unique.


> However, it doesn't prevent users from registering accounts
> with already existing usernames. (I guess that such a feature might be
> used to bruteforce existing usernames.)
>
> The workflow for registrations is pretty awkward in this case. As far as
> I understand, the moderator can't edit the request (and change the
> username) and the user has no way of knowing if the username already
> exists. So I guess the mod has to deny the request and manually write to
> the user 'Hey, username suchandsuch is already taken, please pick
> another one' and the user has to register again. Or the admin has to
> manually create the user and copy all attributes.
>
> Is there a better way to handle this?


Well, I don't think so. We can't just by default check registration 
request whether identities are free (and same about attributes which are 
there) due to what you pointed out, and also as automation of 
registration form may change entered values.

But surely this sounds as an easy to do and sensible feature as a 
configurable option of a form. I.e. that form can be configured 
explicitly by admin so that at submission identities should be checked 
is are available. (*)

Note of course that this won't be 100% accurate: if you have 
non-automatic acceptance a free identity at form submission time may 
become occupied before it is accepted. Reserving identities for pending 
requests would be much more challenging task.

So what do you think about (*)?

Best
KB

[Unity-idm-discuss] Release 3.2.3

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

Dear Subscribers,

Another batch of Unity improvements is available for deployment. This 
time all changes are related to admin console. The most important are 
several changes improving performance and usability of the browser view, 
especially on setups with large number of users and/or groups.

See https://www.unity-idm.eu/downloads/ for a complete changelog.

Best,
Krzysztof

[Unity-idm-discuss] Prevent users from registering existing usernames

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

Hi,

just found out that I can prevent duplicate userNames in unity by
editing the attribute type 'userName' and checking 'Unique values'.
This will prevent moderators from activating accounts with duplicate
usernames. However, it doesn't prevent users from registering accounts
with already existing usernames. (I guess that such a feature might be
used to bruteforce existing usernames.)

The workflow for registrations is pretty awkward in this case. As far as
I understand, the moderator can't edit the request (and change the
username) and the user has no way of knowing if the username already
exists. So I guess the mod has to deny the request and manually write to
the user 'Hey, username suchandsuch is already taken, please pick
another one' and the user has to register again. Or the admin has to
manually create the user and copy all attributes.

Is there a better way to handle this?

Cheers,
D

Re: [Unity-idm-discuss] Fail Authentication in translation profile

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

Hi Sander,

W dniu 21.04.2020 o 08:29, Sander Apweiler pisze:
> Hi Krzysztof,
>
> I found the action "failAuthentication" in output translation profile
> which looks very promising to perform some light wight authorisation.
> The action itself works, but the error message is not displayed and I'm
> redirected to the SP. Is this flow wanted? I would expect that the
> entered error message is displayed to the user and the login flow is
> interrupted.

Yes, it works as implemented: the authentication is failed and the 
failure is returned to the service provider that requested 
authentication (with configured error message given as failure reason, 
in protocol specific way).

Theoretically we could log user out, display error message and... what 
then? Return to authN screen again? User probably has no way out (unless 
has another identity, what is a rather rare case I guess).

Cheers,
Krzysztof

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

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

Hi,

W dniu 22.04.2020 o 17:35, D Baum pisze:
> 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?


Hah, I forgot about case (d): you can also fail authentication in case 
of unknown remote user :-)

You haven't shared a more complete log so can't say for sure, but seems 
that your profile is fine: it maps remote user "dbaum" onto local 
identifier with value "remote-dbaum". This identity is not in DB so 
unknown remote user flow should be triggered (if I could see a log 
around the end of profile execution and just after it, I were sure).

So two things to ensure, both in your remote authenticator config:

 1. that you have enabled account association. For OAuth it is a setting
    of an authnticator. For SAML you can have default setting, and also
    overwrite it per each trusted IDP. For LDAP there is one setting
    (see Interactive Login settings).
 2. that you have configured which registration form should be presented
    to unknown remote users. For SAML authenticators as above: you can
    set one for authenticator, and also overwrite it per IdP. For OAuth
    authenticators it is set per provider (the first option in Advanced
    section). For LDAP sits next to linking.

HTH, if not please provide debug log from input profile an on.


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

Yes. If 90% of users registers, then showing some "link account" option 
will only puzzle them. And those 10% can be instructed that they can go 
to account association endpoint to perform linking (can be also done 
from home UI).

Cheers,
Krzysztof

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

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

[Unity-idm-discuss] Fail Authentication in translation profile

[Sander A. <sa....@fz...>]

Hi Krzysztof,

I found the action "failAuthentication" in output translation profile
which looks very promising to perform some light wight authorisation.
The action itself works, but the error message is not displayed and I'm
redirected to the SP. Is this flow wanted? I would expect that the
entered error message is displayed to the user and the login flow is
interrupted.

Cheers,
Sander
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

[Unity-idm-discuss] Integrating remote IDP

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

Hi,

from the manual I gather that unity supports quite complex scenarios for
combining remote and local authentication - but I wasn't able to piece
together from it how to configure what I need.
I've got local users with username identities who authenticate with
passwords. Now I'd like to add a remote SAML IDP with the following
behaviour:

1. If a user tries remote authentication for a locally existing username
for the first time, they are asked to associate those identities. This
should prevent malicious users from hijacking existing local users'
accounts by registering the same username at the remote IDP.
2. If a user tries remote authenticiation after association with a local
account, they can just log in normally.
3. If a user tries remote authentication and the username doesn't exist
locally, they are shown a pre-filled registration form (with the values
obtained from the remote IDP) where they have to accept the terms and
conditions. Admins are notified and can accept registrations. After
acceptance, the local account is associated with the remote identity.
4. Local login with passwords for existing local users is still
possible. Ideally, newly created remote users are able to set a password
and thus have a 'local' account as well.

I can't quite figure out how to do 1 and 3 yet.

Re 1: How can I force association and not just let remote users in as
soon as the usernames match? I suspect it has to do with the identity
mapping in the input translation profile, described in
http://www.unity-idm.eu/documentation/unity-3.2.1/manual.html#input-translation
but I'm unclear if CREATE_OR_MATCH, MATCH, REQUIRE_MATCH, or
UPDATE_OR_MATCH would be the correct value to chose. And what else is
required to make it work.

Re 3: In my remote saml authentication facility, I've set the
registration form to an existing, public form that collects username and
email 'From remote IdP and shown RO'. However, when testing I'm never
presented with this registration form after remotely authenticating -
seems I'm missing some option?

As a side note: it seems account association can produce entities with
multiple usernames. Both of those usernames will be sent to my SAML SPs
- what's best practice here to avoid weird effects? Can I somehow tell
unity to only send along the username that was created first? Or to
import a new (remote) username only if the entity doesn't already have one?

Cheers,
D

[Unity-idm-discuss] 3.2.2 released

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

Dear Subscribers,

A subsequent revision release 3.2.2 is available for download. This time 
we don't have any major issues, just a bunch of smaller ones.

Besides bug fixes this release brings two small but helpful new features:

  * We have improved debug logging around registration and remote
    authentication flows, which can be helpful to diagnose problems with
    complex configurations.
  * Also it is possible to configure TLS protocol versions supported by
    the server, without relying on proxy or JDK settings.


Details as always: https://www.unity-idm.eu/downloads/


Best,
Krzysztof

Re: [Unity-idm-discuss] LDAP endpoint

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

Hi,

thanks for confirming!
Currently, I can't volunteer the necessary resources on my side, sorry.
So we'll all wait and see ;-)

D

On 15/04/2020 14:49, Krzysztof Benedyczak wrote:
> Hi,
> 
> W dniu 14.04.2020 o 18:39, D Baum pisze:
>> Hi,
>>
>> picking up a very old thread: What's the current status of LDAP
>> endpoint(s) in unity?
>> Is it possible to access unity entities through an LDAP endpoint? Or to
>> automatically create LDAP entries for new entities? If so: how?
>> (Note: I'm not talking about 'outsourcing' authentication to an LDAP
>> server)
> 
> Unfortunately I heard nothing in this topic more or less since that
> time. In other words there is some beta-quality implementation laying
> around in a branch. I can't commit to any stronger push from our team to
> take this over, polish and merge, but we can help if there is some
> volunteer.
> 
> Best,
> Krzysztof
> 

Re: [Unity-idm-discuss] LDAP endpoint

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

Hi,

W dniu 14.04.2020 o 18:39, D Baum pisze:
> Hi,
>
> picking up a very old thread: What's the current status of LDAP
> endpoint(s) in unity?
> Is it possible to access unity entities through an LDAP endpoint? Or to
> automatically create LDAP entries for new entities? If so: how?
> (Note: I'm not talking about 'outsourcing' authentication to an LDAP server)

Unfortunately I heard nothing in this topic more or less since that 
time. In other words there is some beta-quality implementation laying 
around in a branch. I can't commit to any stronger push from our team to 
take this over, polish and merge, but we can help if there is some 
volunteer.

Best,
Krzysztof

Re: [Unity-idm-discuss] LDAP endpoint

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

Hi,

picking up a very old thread: What's the current status of LDAP
endpoint(s) in unity?
Is it possible to access unity entities through an LDAP endpoint? Or to
automatically create LDAP entries for new entities? If so: how?
(Note: I'm not talking about 'outsourcing' authentication to an LDAP server)

Cheers,
D

On 27/07/2018 11:29, Krzysztof Benedyczak wrote:
> Hi Fabian,
> 
> W dniu 26.07.2018 o 10:12, Fabian Mangels pisze:
>>
>> Hi list,
>>
>> Is it possible to integrate an LDAP endpoint in Unity?
>> I would like to access the local entities in the Unity database via
>> LDAP, so that even non-web-based services can use the stored entities
>> in Unity.
>> Or is there another workaround for such a project?
>> Thanks in advance!
> 
> We have a long-lasting effort to expose such functionality in Unity.
> However it was still not integrated into baseline code as there are
> quite a few issues with the code to be solved first. It is hard for me
> to provide timeline for this - depends bit on Willem's help here.
> 
> Alternatives are to use the proprietary REST-admin endpoint of Unity or
> (even better) OAuth, which can be used without web too.
> 
> Best
> Krzysztof
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> _______________________________________________
> Unity-idm-discuss mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss
> 

Re: [Unity-idm-discuss] Storing credentials in browser

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

Hi,

I've solved my immediate issue by manually creating saved credentials in
Firefox (Preferences -> Privacy & Security) -> Saved Logins... -> Create
New Login)
It now prefills the login form like it should, so I'm suspecting it may
be something in my Firefox config that prevents saving passwords.

However, before that I've found some nice sources about optimising for
password managers, maybe they are useful to you:

https://hiddedevries.nl/en/blog/2018-01-13-making-password-managers-play-ball-with-your-login-form

https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands

I tried to test this out with the Inspect Element editor (adding various
features to the HTML live) but unity then complains about missing
inputs, so I guess I'd need to understand VAADIN and how the login forms
are rendered before testing any further.

Cheers,
D


On 06/04/2020 20:19, Krzysztof Benedyczak wrote:
> Hi,
> 
> W dniu 03.04.2020 o 11:14, D Baum pisze:
>> Hi,
>>
>> I've got a feeling that the unit web login endpoint does something to
>> prevent my Firefox from storing the login credentials - is that right?
>>
>> Is there an option to turn this off for testing purposes? Testing the
>> login process and always re-entering the credentials is a bit of a
>> pain...
> 
> Nothing intentional here. I've noticed that FF has a problem with
> capturing credentials. Chrome works fine and at least 1password from
> commercial passs managers. I guess something is not suiting FF from
> field metadata but I never got to particular HTML/CSS element that is
> causing it.
> 
> If you find what is that "something" let me know, may be easy to fix,
> especially if this is CSS related.
> 
> Best,
> Krzysztof
> 

Re: [Unity-idm-discuss] Storing credentials in browser

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

Hi,

W dniu 03.04.2020 o 11:14, D Baum pisze:
> Hi,
>
> I've got a feeling that the unit web login endpoint does something to
> prevent my Firefox from storing the login credentials - is that right?
>
> Is there an option to turn this off for testing purposes? Testing the
> login process and always re-entering the credentials is a bit of a pain...

Nothing intentional here. I've noticed that FF has a problem with 
capturing credentials. Chrome works fine and at least 1password from 
commercial passs managers. I guess something is not suiting FF from 
field metadata but I never got to particular HTML/CSS element that is 
causing it.

If you find what is that "something" let me know, may be easy to fix, 
especially if this is CSS related.

Best,
Krzysztof

[Unity-idm-discuss] Storing credentials in browser

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

Hi,

I've got a feeling that the unit web login endpoint does something to
prevent my Firefox from storing the login credentials - is that right?

Is there an option to turn this off for testing purposes? Testing the
login process and always re-entering the credentials is a bit of a pain...

Cheers,
D

Re: [Unity-idm-discuss] Unity keeps requesting a client certificate from my users

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

On 02/04/2020 15:39, Krzysztof Benedyczak wrote:
> well, if you don't have a personal certificate installed in your
> browser's keystore, what is true for 99+% users then you won't be bugged
> by the browser (with exception of Safari AFAIR). So that's not that bad
> in general. But true we can think about changing the default, it used to
> be more needed in the past. Especially as TLS authN is passing away with
> FIDO2/WebAuthn.

This seems to be happening in both Safari and Chrome on Macs but not in
Firefox. Didn't happen in my Linux Firefox. I haven't tested with Chrome
anywhere else.

Now that I know about the setting, I'm not to bothered by the issue but
for someone doing a fresh install this might come quite unexpected.