unity-idm-discuss — Unity discussion and support

[Unity-idm-discuss] fail Authentication action in translation profile

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

Good morning Krzysztof,
we tested the fail Authentication action in the translation profiles to
do a lightweight ABAC/authorisation within unity for service who can't
do it by itself.
We encountered some problems/not optimal behaviour in it. The error
message is only send to service, but not to the users. The services can
not handle such specific error messages and the user get a very strange
error at the service. E.g. the error of Nextcloud is:
"Account not provisioned.
Your account is not provisioned, access to this service is thus not
possible."

The user do not really understand why the login fails. From our point
of view it would be great if the failed authentication error is shown
to the user, maybe with the possibility to login with another account.
Do you see a possibility to extend the fail authentication behaviour?

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

[Unity-idm-discuss] Issue with remember me function

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

Good morning Krzysztof,

we have an issue on one of our four unity (3.2.2) instances with the
remember me function. It is not working. When I log out from a service
and from unity, by passing the session lifetime or logging out in a
second browser tab, and try to re-login, I see all connected IdPs but
not the screen with my last one. This issue appears with all browsers
and with different users. The log does not show any errors. The
remember me configuration is the default configuration. Do you have
seen this issue/behaviour before?

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

[Unity-idm-discuss] Release 3.3.0 is out

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

Dear Subscribers,

Unity 3.3.0 release brings a large set of improvements and brand new 
features. Additionally couple of bugs were fixed, see in the detailed 
changelog at https://www.unity-idm.eu/downloads/


          Policy documents

Policy documents are a new global concept in Unity. Administrator can 
define documents covering ToU, SLA, marketing agreements and any other 
alike. Documents are versioned, can be provided in multiple forms and 
can be mandatory or optional.

Defined policy documents can be configured as a part of registration, 
enquiry or sign-in over IdP endpoint flows. Unity will record (as a 
special user attribute) acceptance or refusal, allowing to re-prompt 
after document update. It is additionally possible to configure in what 
way acceptance should be requested.


          One time passwords

A new credential type is available: one time codes, technically the 
popular TOTP variant. It is a credential useful typically as the 2nd 
factor in two step authentication.

With this credential users can verify their identity with help of Google 
Authenticator, Microsoft Authenticator, RedHat’s FreeOTP or any other 
similar app.


          Other notable improvements

  * Shared translation profiles can be managed in Admin Console now.
  * Default appearance of the authentication screen (and all other
    views) was improved a lot, aligned and unified with general Unity style.
  * Authentication screen appearance on narrow mobile screens was
    improved in case of multiple columns with authentication options.
  * Registration form can be configured to deny request using an
    occupied identity at submission time.
  * Credentials editing in Admin Console and HomeUI was reworked and
    offers much better UX now.
  * MFA preference can be controlled with registration form action
  * We started to provide a more intuitive contextual help in Admin
    Console. Only few components use this feature so far, but we will
    expand it in the next revisions. For examples see Realms or OTP
    credential definition.



Downloads and more detailed changelog available as usual at 
https://www.unity-idm.eu/downloads/

Note: we haven't yet published the RPM package due to problems with 
release server. It will be available in the next few days.

Best regards,
Krzysztof

[Unity-idm-discuss] Moving to Maven Central Repository

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

Dear Subscribers,

[This notice is relevant only for Unity users who are /developing 
against Unity //Java//APIs/]

As you could noticed the delay between 3.2 and an upcoming 3.3 release 
was bigger than usual. It was caused partially by an undertaken effort 
to move Unity from the Maven repository hosted by courtesy of 
Forschungszentrum Jülich to the Maven Central.

That was a complex process as many of Unity dependencies where also 
hosted there. With Bernd's support, we managed to migrate all Unity 
dependencies to GitHub from Sourceforge, and we have deployed them to 
Maven Central. Hopefully this means that from the next Unity release all 
Unity artefacts will be available from the most popular repository in 
JVM ecosystem. This brings many benefits:

I'd like to express here my gratitude to FZJ for hosting Unity Maven 
repo, free of charge, for something around 7 years, and more personally 
pass big thanks to Bernd, who helped with the whole action of moving to 
GitHub and Maven Central.

Technically the move to Maven Central Repository required us to change 
Maven's groupId of all Unity artifacts (as well as few dependencies that 
we maintain). From Unity version 3.3.0 all Maven artifacts will live in 
the group "io.imunity". Artifact ids were not modified, version numbers 
are continued.

Best,
Krzysztof

[Unity-idm-discuss] New Unity logo

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

Dear Subscribers,

We have couple of news to share, as we are getting close to the next 
feature release.

First news was probably already noticed by some of you visiting unity 
website recently: Unity got a new logo.
We have finished rebranding process, and it will be also a default 
product icon configured by default in distribution.

We hope you will like it, as much as we do :-)


New Unity logo


Best,
Krzysztof

Re: [Unity-idm-discuss] Issues with OAuth client logos not using jpeg

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

Hi Sander,

W dniu 02.06.2020 o 06:53, Sander Apweiler pisze:
> Good morning Krzysztof,
>
> I found an issue in Oauth client registration with non jpeg logos.
> Unity accept them while uploading and displaying them in the
> registration request. When I want to accept them, I get an error
> because the logo is not an jpeg. I attached the log. Should unity only
> handle jpegs? IMHO: In this case the check should be done while
> uploading.
>
> We are using unity 3.2.2.


Yeah, thanks for bringing it up. That is still small thing we need to 
align. Long time ago Unity supported only JPEG images as attribute 
value. More recently we added a much better attribute syntax which 
handles also other web-enabled picture formats and also fixes some of 
the original type problems like double compression. This new type is 
available for regular attribtues, but we haven't prepare a migration 
changing system-defined attribute types (like oauth client's logo) to 
the new format.

I'll open a ticket to clean this up finally and also drop the old syntax.

Thanks,
Krzysztof

[Unity-idm-discuss] Issues with OAuth client logos not using jpeg

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

Good morning Krzysztof,

I found an issue in Oauth client registration with non jpeg logos.
Unity accept them while uploading and displaying them in the
registration request. When I want to accept them, I get an error
because the logo is not an jpeg. I attached the log. Should unity only
handle jpegs? IMHO: In this case the check should be done while
uploading.

We are using unity 3.2.2.

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] TOTP as second factor - Time schedule?

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

Hi,

W dniu 27.05.2020 o 12:44, Tim Kreuzer pisze:
> Hi,
>
> I'm very interested in the (not yet available) local credential "One
> time password" feature. Are you able to estimate when this feature will
> find it's way into Unity? Do you already know which kind of OTP this
> will be (support of the Google Authenticator app, for example?). Thank
> you for any information.

I have bit bad news here. While ago we intended to work on OTP as on the 
next Unity authenticator, but we changed our plans and current work is 
focusing on FIDO2 (aka webAuthn) authenticator. This is already pretty 
much working, sooner then later should be officially available. OTP work 
was therefore not yet started and I can't provide an ETA. We can cover 
it as a sponsored development faster, otherwise it is not on the near 
term horizon, though certainly still on the roadmap.

Google Authenticator should work with the planned implementation (at 
least back when I was checking it, it was implementing the standard HOTP 
algorithm) as well all other typical apps like FreeOTP.

Best
Krzysztof

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

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

hi,

W dniu 13.05.2020 o 09:47, Marcus Hardt pisze:
> 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.

You mean that Unity is acting as OIDC client? If so then either:

-> you auto create user account: covered already, just map this incoming 
username to any identity in Unity.

-> you request user to register and registration request waits for 
approval: then it is exactly this case discussed here and the same 
feature will help

Best,
KB

[Unity-idm-discuss] TOTP as second factor - Time schedule?

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

Hi,

I'm very interested in the (not yet available) local credential "One
time password" feature. Are you able to estimate when this feature will
find it's way into Unity? Do you already know which kind of OTP this
will be (support of the Google Authenticator app, for example?). Thank
you for any information.


Best regards,
Tim




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

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

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

Hi Sander,

W dniu 11.05.2020 o 12:40, Sander Apweiler pisze:
> 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?
>
Well, in general all those identifiers always should be treated as case 
sensitive, both in 3.2 and 2.8 and before.

It can happen, though, and we hit it multiple times here too, that 
case-insensitive DB collation setting may allow for using different 
cases, which are still working fine. Maybe this was a case? It is 
especially hard when collation changes between different DBs, e.g. after 
migration.

Also I guess there was some additional issue with update of 
configuration, but I'm not able to decipher what exactly happened.

Cheers,
Krzysztof

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