unity-idm-discuss — Unity discussion and support

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

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

Hi Krzysztof,
we plan to create some public OAauth client which can be used for OIDC
agents. We do not want to have changes in the credential or return URL
by users of this client and prohibit the login in userhome. We tested
it with status login disabled but we got the following error:

'{"message":"Invalid user name, credential or external authentication 
failed. ","error":"AuthenticationException"}'

With enabled status the client is working.

Do you have some idea or hint how we could reach our target?

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,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

[Unity-idm-discuss] Update 3.1.4 is out

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

Dear Subscribers,

Most likely the final revision in 3.1 branch is available. We wanted to 
release all pending fixes that we had worked on, before the next feature 
release. The 3.2.0 should be available in the next week or two.

This release brings couple of minor improvements of UI and updates 
GitHub authenticator configuration to use newly recommended settings. 
The most important bugfix is related to image loading in administrative 
interfaces.

3.1.4 is available as usual from Downloads 
<https://www.unity-idm.eu/downloads/>

Best regards,
Krzysztof

Re: [Unity-idm-discuss] Registration and enquiry forms for upman are not working on unity 3

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

And one more thing:

W dniu 12.02.2020 o 13:20, Sander Apweiler pisze:
> Hi Krzysztof,
>
> we encountered a problem with registration and enquiry forms for upman
> within unity 3.1.3.
>
> Every time when we try to edit or copy a form from for upman, we get
> some errors. They occur in admin and console endpoint but in different
> ways.
> 1) admin endpoint
> It shows an error about checking invalid and mandatory values
> (admin.png) and the attached stacktrace is raised in logs.
> 2) console endpoint
> The edit form is not loaded and we see an empty screen (console.png).
> Within the logs nothing appears.
>
> The error does not appers when we edit forms for the normal user
> registration to unity itself.
>
> With unity 2.8.2 we can do all operations.

if you could send me info (can be from 2.8.2) what is the configuration 
of form logo there, I'd be able to double check if the error you get is 
indeed the one we have fixed.

Thanks
KB

PS 3.2.0 should be out pretty soon too, maybe even next week.

Re: [Unity-idm-discuss] Registration and enquiry forms for upman are not working on unity 3

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

Hi Sander,

W dniu 12.02.2020 o 13:20, Sander Apweiler pisze:
> Hi Krzysztof,
>
> we encountered a problem with registration and enquiry forms for upman
> within unity 3.1.3.
>
> Every time when we try to edit or copy a form from for upman, we get
> some errors. They occur in admin and console endpoint but in different
> ways.
> 1) admin endpoint
> It shows an error about checking invalid and mandatory values
> (admin.png) and the attached stacktrace is raised in logs.
> 2) console endpoint
> The edit form is not loaded and we see an empty screen (console.png).
> Within the logs nothing appears.
>
> The error does not appers when we edit forms for the normal user
> registration to unity itself.
>
> With unity 2.8.2 we can do all operations.

This bug was a regression, not very much related to the upman forms, 
just a general, related to image handling.

Is already fixed from quite some time but not yet released. Tomorrow 
I'll do a 3.1.4 patch release with this and couple of more fixes which 
we have ready to go.

Thanks for the heads up,Krzysztof

[Unity-idm-discuss] Registration and enquiry forms for upman are not working on unity 3

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

Hi Krzysztof,

we encountered a problem with registration and enquiry forms for upman
within unity 3.1.3.

Every time when we try to edit or copy a form from for upman, we get
some errors. They occur in admin and console endpoint but in different
ways.
1) admin endpoint
It shows an error about checking invalid and mandatory values
(admin.png) and the attached stacktrace is raised in logs.
2) console endpoint
The edit form is not loaded and we see an empty screen (console.png).
Within the logs nothing appears.

The error does not appers when we edit forms for the normal user
registration to unity itself. 

With unity 2.8.2 we can do all operations.

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,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Github Authenticator depricated

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

Hi Sander,

W dniu 10.02.2020 o 09:43, Sander Apweiler pisze:
> Hi Krzysztof,
>
> I got an email from Github that Unitys authenticator uses deprecated
> API. Is it already updated in v3?
>
Will be in 3.2.0. Anyway this should be very easy to fix even without 
update with one config line added. I'll try to verify this and let you know.

Cheers,
KB

[Unity-idm-discuss] Github Authenticator depricated

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

Hi Krzysztof,

I got an email from Github that Unitys authenticator uses deprecated
API. Is it already updated in v3?

Mail from GH:
Hello there!

On February 10th, 2020 at 07:49 (UTC) your application (EUDAT B2ACCESS)
used an access token (with the User-Agent Java/1.8.0_232) as part of a
query parameter to access an endpoint through the GitHub API.

https://api.github.com/user

Please use the Authorization HTTP header instead as using the
`access_token` query parameter is deprecated and will be removed July
1st, 2020.

Depending on your API usage, we'll be sending you this email reminder
once every 3 days.

Visit 
https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters
for more information.

Thanks,
The GitHub Team

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,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Push notifications on group changes

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

On 01/20/20 22:14, Krzysztof Benedyczak wrote:
> Hi Marcus,
> 
> W dniu 15.01.2020 o 12:12, Marcus Hardt pisze:
> > On 01/14/20 11:06, Marcus Hardt wrote:
> > > On 01/14/20 08:56, Krzysztof Benedyczak wrote:
> > > > Dear Sander,
> > > > 
> > > > W dniu 13.01.2020 o 14:32, Sander Apweiler pisze:
> > > > > Dear Krzysztof,
> > > > > 
> > > > > on one of our unity instance we use the group management of unity and
> > > > > service grant access/quotas based on group membership. Some of the
> > > > > service use unity only for account creation and thereafter users have
> > > > > access possibilities which bypass unity. In this cases the group
> > > > > membership information needs to be updated regularly.
> > > > > 
> > > > > The administrators of this services asked if unity is able to send push
> > > > > notifications to the group membership as changed. AFAIK unity does not
> > > > > offer this, but can it be covered by groovy script extensions?
> > > > Yes, all of that should be possible. Groovy script can get triggered when
> > > > user is added and removed from any group.
> > > > 
> > > > After enabling low-level events and their logging check for events around
> > > > GroupsManagement . addMemberFromParent and removeMember events.
> > > > 
> > > > http://www.unity-idm.eu/documentation/unity-3.1.0/apidocs/index.html
> > > > 
> > > > In context you will get EntityParam which you can use in groovy o obtain any
> > > > information about a user you need.
> > > That sounds good!
> > > 
> > > > The only downside of it is that you need to check this after each unity
> > > > update, we do not guarantee stability of those internal interfaces. Though
> > > > good news is those basic ones change extremely rarely.
> > > Let's hope for the best.
> > > 
> > > > > The administrators also ask if it would be possible to tell which
> > > > > entity has changed and also to provide an access token. The service
> > > > > will use this to update the local (service) user representation with
> > > > > querying the user info endpoint. Would it be possible to put some of
> > > > > this information in the (script based) notification?
> > > > So regarding entity details it is possible. You can also push all relevant
> > > > attributes of the user with the notification.
> > > > 
> > > > I'm not sure about what access token you want here. Certainly it is possible
> > > > to generate something, but I don't have understanding of requirements here
> > > > (and why not to simply push required info without additional call)
> > > The way we update the information in our tool (FEUDAL) is that whenever a
> > > rest enpoint is called, we verify the AT by calling the UserInfoEndpoint.
> > > Therefore, we use that to update our user object.
> > > 
> > > There is also the authenticity of information. We cannot accept anybody
> > > sending us a JSON with an update on userinfo. We need some kind of
> > > authorisation / authentication for this.
> > > 
> > > Therefore, it would be cleanest on our side.
> > > 
> > > If this is unreasonable on the unity side, sending a JSON is ok, but we
> > > need some kind of signature on it.
> > Another option for us would be to request refresh-tokens, and use the JSON
> > sent solely to trigger a user update.  This is not very clean either, and
> > seems to require most code changes on both sides.
> 
> You can go with any of the described approaches. Personally I'd consider
> keeping to KISS: adding a unique random token as an authentication of the
> sender on Unity side + all information consumer will need so no subsequent
> callback is needed. But if you want to go any harder path you can generate
> AT/signature/MAC and use it in Groovy script.
@Sander: How do we proceed?

From our side, what I'd need would be:

- Mandatory:
  - a json with sub and iss about the user concerning the change

- Optional:
  - Extremely cool: An access token of the person (in that case the
    above JSON only need to contain the iss (which is automatic in unity
    3.4.0))

This you would send (post?) to an endpoint that I'd give you. It's
probably the same endpoint for each VO.

<offtopic>
Regarding VO, I yesterday saw some of the FZJ people praising their future
use of the unity VO implementation.
Great Success!
</offtopic>

> BTW: good news, you can expect JWT AT in unity 3.4.0.
Very Cool!!

-- 
Marcus.

Re: [Unity-idm-discuss] Push notifications on group changes

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

Hi Marcus,

W dniu 15.01.2020 o 12:12, Marcus Hardt pisze:
> On 01/14/20 11:06, Marcus Hardt wrote:
>> On 01/14/20 08:56, Krzysztof Benedyczak wrote:
>>> Dear Sander,
>>>
>>> W dniu 13.01.2020 o 14:32, Sander Apweiler pisze:
>>>> Dear Krzysztof,
>>>>
>>>> on one of our unity instance we use the group management of unity and
>>>> service grant access/quotas based on group membership. Some of the
>>>> service use unity only for account creation and thereafter users have
>>>> access possibilities which bypass unity. In this cases the group
>>>> membership information needs to be updated regularly.
>>>>
>>>> The administrators of this services asked if unity is able to send push
>>>> notifications to the group membership as changed. AFAIK unity does not
>>>> offer this, but can it be covered by groovy script extensions?
>>> Yes, all of that should be possible. Groovy script can get triggered when
>>> user is added and removed from any group.
>>>
>>> After enabling low-level events and their logging check for events around
>>> GroupsManagement . addMemberFromParent and removeMember events.
>>>
>>> http://www.unity-idm.eu/documentation/unity-3.1.0/apidocs/index.html
>>>
>>> In context you will get EntityParam which you can use in groovy o obtain any
>>> information about a user you need.
>> That sounds good!
>>
>>> The only downside of it is that you need to check this after each unity
>>> update, we do not guarantee stability of those internal interfaces. Though
>>> good news is those basic ones change extremely rarely.
>> Let's hope for the best.
>>
>>>> The administrators also ask if it would be possible to tell which
>>>> entity has changed and also to provide an access token. The service
>>>> will use this to update the local (service) user representation with
>>>> querying the user info endpoint. Would it be possible to put some of
>>>> this information in the (script based) notification?
>>> So regarding entity details it is possible. You can also push all relevant
>>> attributes of the user with the notification.
>>>
>>> I'm not sure about what access token you want here. Certainly it is possible
>>> to generate something, but I don't have understanding of requirements here
>>> (and why not to simply push required info without additional call)
>> The way we update the information in our tool (FEUDAL) is that whenever a
>> rest enpoint is called, we verify the AT by calling the UserInfoEndpoint.
>> Therefore, we use that to update our user object.
>>
>> There is also the authenticity of information. We cannot accept anybody
>> sending us a JSON with an update on userinfo. We need some kind of
>> authorisation / authentication for this.
>>
>> Therefore, it would be cleanest on our side.
>>
>> If this is unreasonable on the unity side, sending a JSON is ok, but we
>> need some kind of signature on it.
> Another option for us would be to request refresh-tokens, and use the JSON
> sent solely to trigger a user update.  This is not very clean either, and
> seems to require most code changes on both sides.

You can go with any of the described approaches. Personally I'd consider 
keeping to KISS: adding a unique random token as an authentication of 
the sender on Unity side + all information consumer will need so no 
subsequent callback is needed. But if you want to go any harder path you 
can generate AT/signature/MAC and use it in Groovy script.

BTW: good news, you can expect JWT AT in unity 3.4.0.

Cheers,
Krzysztof

Re: [Unity-idm-discuss] Push notifications on group changes

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

On 01/14/20 11:06, Marcus Hardt wrote:
> On 01/14/20 08:56, Krzysztof Benedyczak wrote:
> > Dear Sander,
> > 
> > W dniu 13.01.2020 o 14:32, Sander Apweiler pisze:
> > > Dear Krzysztof,
> > > 
> > > on one of our unity instance we use the group management of unity and
> > > service grant access/quotas based on group membership. Some of the
> > > service use unity only for account creation and thereafter users have
> > > access possibilities which bypass unity. In this cases the group
> > > membership information needs to be updated regularly.
> > > 
> > > The administrators of this services asked if unity is able to send push
> > > notifications to the group membership as changed. AFAIK unity does not
> > > offer this, but can it be covered by groovy script extensions?
> > 
> > Yes, all of that should be possible. Groovy script can get triggered when
> > user is added and removed from any group.
> > 
> > After enabling low-level events and their logging check for events around
> > GroupsManagement . addMemberFromParent and removeMember events.
> > 
> > http://www.unity-idm.eu/documentation/unity-3.1.0/apidocs/index.html
> > 
> > In context you will get EntityParam which you can use in groovy o obtain any
> > information about a user you need.
> That sounds good!
> 
> > The only downside of it is that you need to check this after each unity
> > update, we do not guarantee stability of those internal interfaces. Though
> > good news is those basic ones change extremely rarely.
> Let's hope for the best.
> 
> > > The administrators also ask if it would be possible to tell which
> > > entity has changed and also to provide an access token. The service
> > > will use this to update the local (service) user representation with
> > > querying the user info endpoint. Would it be possible to put some of
> > > this information in the (script based) notification?
> > 
> > So regarding entity details it is possible. You can also push all relevant
> > attributes of the user with the notification.
> > 
> > I'm not sure about what access token you want here. Certainly it is possible
> > to generate something, but I don't have understanding of requirements here
> > (and why not to simply push required info without additional call)
> The way we update the information in our tool (FEUDAL) is that whenever a
> rest enpoint is called, we verify the AT by calling the UserInfoEndpoint.
> Therefore, we use that to update our user object.
> 
> There is also the authenticity of information. We cannot accept anybody
> sending us a JSON with an update on userinfo. We need some kind of
> authorisation / authentication for this.
> 
> Therefore, it would be cleanest on our side. 
> 
> If this is unreasonable on the unity side, sending a JSON is ok, but we
> need some kind of signature on it.

Another option for us would be to request refresh-tokens, and use the JSON
sent solely to trigger a user update.  This is not very clean either, and
seems to require most code changes on both sides.

-- 
Marcus.

Re: [Unity-idm-discuss] Push notifications on group changes

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

On 01/14/20 08:56, Krzysztof Benedyczak wrote:
> Dear Sander,
> 
> W dniu 13.01.2020 o 14:32, Sander Apweiler pisze:
> > Dear Krzysztof,
> > 
> > on one of our unity instance we use the group management of unity and
> > service grant access/quotas based on group membership. Some of the
> > service use unity only for account creation and thereafter users have
> > access possibilities which bypass unity. In this cases the group
> > membership information needs to be updated regularly.
> > 
> > The administrators of this services asked if unity is able to send push
> > notifications to the group membership as changed. AFAIK unity does not
> > offer this, but can it be covered by groovy script extensions?
> 
> Yes, all of that should be possible. Groovy script can get triggered when
> user is added and removed from any group.
> 
> After enabling low-level events and their logging check for events around
> GroupsManagement . addMemberFromParent and removeMember events.
> 
> http://www.unity-idm.eu/documentation/unity-3.1.0/apidocs/index.html
> 
> In context you will get EntityParam which you can use in groovy o obtain any
> information about a user you need.
That sounds good!

> The only downside of it is that you need to check this after each unity
> update, we do not guarantee stability of those internal interfaces. Though
> good news is those basic ones change extremely rarely.
Let's hope for the best.

> > The administrators also ask if it would be possible to tell which
> > entity has changed and also to provide an access token. The service
> > will use this to update the local (service) user representation with
> > querying the user info endpoint. Would it be possible to put some of
> > this information in the (script based) notification?
> 
> So regarding entity details it is possible. You can also push all relevant
> attributes of the user with the notification.
> 
> I'm not sure about what access token you want here. Certainly it is possible
> to generate something, but I don't have understanding of requirements here
> (and why not to simply push required info without additional call)
The way we update the information in our tool (FEUDAL) is that whenever a
rest enpoint is called, we verify the AT by calling the UserInfoEndpoint.
Therefore, we use that to update our user object.

There is also the authenticity of information. We cannot accept anybody
sending us a JSON with an update on userinfo. We need some kind of
authorisation / authentication for this.

Therefore, it would be cleanest on our side. 

If this is unreasonable on the unity side, sending a JSON is ok, but we
need some kind of signature on it.


Cheers,
-- 
Marcus.

Re: [Unity-idm-discuss] Push notifications on group changes

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

Dear Sander,

W dniu 13.01.2020 o 14:32, Sander Apweiler pisze:
> Dear Krzysztof,
>
> on one of our unity instance we use the group management of unity and
> service grant access/quotas based on group membership. Some of the
> service use unity only for account creation and thereafter users have
> access possibilities which bypass unity. In this cases the group
> membership information needs to be updated regularly.
>
> The administrators of this services asked if unity is able to send push
> notifications to the group membership as changed. AFAIK unity does not
> offer this, but can it be covered by groovy script extensions?

Yes, all of that should be possible. Groovy script can get triggered 
when user is added and removed from any group.

After enabling low-level events and their logging check for events 
around GroupsManagement . addMemberFromParent and removeMember events.

http://www.unity-idm.eu/documentation/unity-3.1.0/apidocs/index.html

In context you will get EntityParam which you can use in groovy o obtain 
any information about a user you need.

The only downside of it is that you need to check this after each unity 
update, we do not guarantee stability of those internal interfaces. 
Though good news is those basic ones change extremely rarely.

> The administrators also ask if it would be possible to tell which
> entity has changed and also to provide an access token. The service
> will use this to update the local (service) user representation with
> querying the user info endpoint. Would it be possible to put some of
> this information in the (script based) notification?

So regarding entity details it is possible. You can also push all 
relevant attributes of the user with the notification.

I'm not sure about what access token you want here. Certainly it is 
possible to generate something, but I don't have understanding of 
requirements here (and why not to simply push required info without 
additional call)


HTH

Krzysztof

[Unity-idm-discuss] Push notifications on group changes

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

Dear Krzysztof,

on one of our unity instance we use the group management of unity and
service grant access/quotas based on group membership. Some of the
service use unity only for account creation and thereafter users have
access possibilities which bypass unity. In this cases the group
membership information needs to be updated regularly.

The administrators of this services asked if unity is able to send push
notifications to the group membership as changed. AFAIK unity does not
offer this, but can it be covered by groovy script extensions?

The administrators also ask if it would be possible to tell which
entity has changed and also to provide an access token. The service
will use this to update the local (service) user representation with
querying the user info endpoint. Would it be possible to put some of
this information in the (script based) notification?

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,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Inspector is not authorized to read members in unity 2.8.2

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

Dear Sander,

W dniu 06.01.2020 o 08:08, Sander Apweiler pisze:
> Dear Krzysztof,
>
> It seems that it is lost in the database:

Yeah, certainly. Any ideas whether this role was dropped during some of 
migrations, or maybe was missing from the very beginning?

I.e. have you ever used this missing role on the system in question? Or 
you rather suspect that this is result of recent migration (if yes 
knowing start version would help)?

> Because on other instances we have this role, do you know a database
> query to create it?

Yes, however this is pretty low level.

You need to do this either on DB (SQL UPDATE) or export the JSON dump, 
fix it there, and import.

In any case the missing role needs to be added to the JSON describing 
the attribute type.

So in case of DB:

1. take backup :-)

2. in table ATTRIBUTE_TYPES identify PKEY (ID column) of record with 
NAME = 'sys:AuthorizationRole' and the current, malformed CONTENTS 
column value of the record.

3. update record CONTENTS column with the ID from the above point so it 
has the same contents as originally, but additionally the allowed part 
in syntaxState is as follows:

"syntaxState":{"allowed":["Privileged Inspector","Anonymous 
User","Inspector","System Manager","Contents Manager","Regular User"]}

(the rest should be intact - i.e. you will need to add this "Privileged 
Inspector", string)


HTH
KB

Re: [Unity-idm-discuss] Inspector is not authorized to read members in unity 2.8.2

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

Dear Krzysztof,

On Fri, 2020-01-03 at 12:11 +0100, Krzysztof Benedyczak wrote:
> Dear Sander,
> 
> Happy New Year!
> 
> W dniu 02.01.2020 o 07:34, Sander Apweiler pisze:
> > Dear Krzysztof,
> > first of all I wish you a happy new year and all the best for 2020.
> > 
> > Upgrading to privileged inspector would be ok, but I don't have
> > this
> > role anymore. The drop down list does not contain it. It is still
> > listed in the explanation of the roles, but not available.
> > 
> Uh! That's very strange. I have no guess around what happened. Couple
> of 
> ideas to get us started:
> 
> 1. What drop down has no priv inspector? AdminUI -> Contents
> Management 
> -> setting an attribute? Or elsewhere?
Yes in AdminUI -> Contents Management -> setting an attribute. See
screenshot.
> 
> 2. Can you try to play with this a bit? E.g. can you set this
> attribute 
> for new (even test) user?
Same behaviour.
> 
> 3. Can you create a DB JSON dump and inspect what is in 
> sys:Authorizationrole attribute type? Having this may help.
It seems that it is lost in the database:

{
       "flags" : 1,
       "maxElements" : 10,
       "minElements" : 1,
       "selfModificable" : false,
       "uniqueValues" : true,
       "syntaxState" : {
         "allowed" : [ "Anonymous User", "Inspector", "Regular User", "Contents Manager", "System Manager" ]
       },
       "displayedName" : {
         "DefaultValue" : "sys:AuthorizationRole",
         "Map" : {
           "pl" : "Rola autoryzacyjna",
           "en" : "Authorization role"
         }
       },
       "i18nDescription" : {
         "DefaultValue" : null,
         "Map" : {
           "pl" : "Definiuje jakie operacje są dozwolone dla posiadacza. Wpływa na dostęp do grupy w której atrybut jest przydzielony oraz wszystkich podgrupach, gdzie może być nadpisany. Dostępne role:\n<b>System Manager</b> - Syst       em manager with all privileges.\n<b>Contents Manager</b> - Allows for performing all management operations related to groups, entities and attributes. Also allows for reading information about hidden attributes.\n<b>Privileged Insp       ector</b> - Allows for reading entities, groups and attributes, including the attributes visible locally only. No modifications are possible\n<b>Inspector</b> - Allows for reading entities, groups and attributes. No modifications a       re possible\n<b>Regular User</b> - Allows owners for reading of the basic system information, retrieval of information about themselves and also for changing passwords and self managed attributes\n<b>Anonymous User</b> - Allows for        minimal access to the system: owners can get basic system information and retrieve information about themselves\n",
           "en" : "Defines what operations are allowed for the bearer. The attribute of this type defines the access in the group where it is defined and in all subgroups. In subgroup it can be redefined to grant more access. Roles:       \n <b>System Manager</b> - System manager with all privileges.\n<b>Contents Manager</b> - Allows for performing all management operations related to groups, entities and attributes. Also allows for reading information about hidden        attributes.\n<b>Privileged Inspector</b> - Allows for reading entities, groups and attributes, including the attributes visible locally only. No modifications are possible\n<b>Inspector</b> - Allows for reading entities, groups and        attributes. No modifications are possible\n<b>Regular User</b> - Allows owners for reading of the basic system information, retrieval of information about themselves and also for changing passwords and self managed attributes\n<b>       Anonymous User</b> - Allows for minimal access to the system: owners can get basic system information and retrieve information about themselves\n"
         }
       },
       "metadata" : { },
       "name" : "sys:AuthorizationRole",
       "syntaxId" : "enumeration"
     },
> 
> 4. Can you set this attribute over REST API?
I did not test it because it was not in the database.

Because on other instances we have this role, do you know a database
query to create it?

Cheers,
Sander
> 
> Cheers,
> KB
> 
-- 
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,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Inspector is not authorized to read members in unity 2.8.2

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

Dear Sander,

Happy New Year!

W dniu 02.01.2020 o 07:34, Sander Apweiler pisze:
> Dear Krzysztof,
> first of all I wish you a happy new year and all the best for 2020.
>
> Upgrading to privileged inspector would be ok, but I don't have this
> role anymore. The drop down list does not contain it. It is still
> listed in the explanation of the roles, but not available.
>
Uh! That's very strange. I have no guess around what happened. Couple of 
ideas to get us started:

1. What drop down has no priv inspector? AdminUI -> Contents Management 
-> setting an attribute? Or elsewhere?

2. Can you try to play with this a bit? E.g. can you set this attribute 
for new (even test) user?

3. Can you create a DB JSON dump and inspect what is in 
sys:Authorizationrole attribute type? Having this may help.

4. Can you set this attribute over REST API?

Cheers,
KB

Re: [Unity-idm-discuss] Inspector is not authorized to read members in unity 2.8.2

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

Dear Krzysztof,
first of all I wish you a happy new year and all the best for 2020.

Upgrading to privileged inspector would be ok, but I don't have this
role anymore. The drop down list does not contain it. It is still
listed in the explanation of the roles, but not available.

Cheers,
Sander

On Fri, 2019-12-27 at 16:50 +0100, Krzysztof Benedyczak wrote:
> Hi Sander,
> 
> W dniu 19.12.2019 o 13:07, Sander Apweiler pisze:
> > Dear Krzysztof,
> > 
> > we have some users who has Inspector privileges. Since we updated
> > to
> > unity 2.8.2 this users got the error "Not authorized to read
> > members of
> > the group" when they try to view the users in admin endpoint. Was
> > this
> > changed behaviour planed?
> 
> Yes.
> 
> We have added a lot of optimizations in recent versions, in order to 
> have a fast operation on huge groups. A side effect of this is that
> in 
> both adminUI and the new console browsing of groups contents requires
> a 
> slightly higher privilege. Previously we had a very detailed
> filtering 
> of data returned for role of inspector. Now it was simplified, and
> while 
> authorization works in the same way (i.e. Inspector can access the
> same 
> data it could before) it is not enough to use Console UI/Admin UI
> which 
> are using simplier API for performance. We could also support the 
> original Inspector role, but it would require a separate optimized 
> implementation and at the same time we believe that AdminUI/Console 
> should be rather used by privileged users.
> 
> The solution is quite straightforward: the "Privileged inspector"
> role 
> has enough capabilities to use console/adminUI in RO mode, so use it
> for 
> RO users of Console/AdminUI. The "Inspector" role is still useful as
> a 
> more limited user on REST API. The difference between the two roles
> is 
> that Privileged inspector can read also some of the data "hidden"
> from 
> outside world, like disabled entities, which are not shown to the
> plain 
> "Inspector".
> 
> HTH,
> 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,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Inspector is not authorized to read members in unity 2.8.2

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

Hi Sander,

W dniu 19.12.2019 o 13:07, Sander Apweiler pisze:
> Dear Krzysztof,
>
> we have some users who has Inspector privileges. Since we updated to
> unity 2.8.2 this users got the error "Not authorized to read members of
> the group" when they try to view the users in admin endpoint. Was this
> changed behaviour planed?

Yes.

We have added a lot of optimizations in recent versions, in order to 
have a fast operation on huge groups. A side effect of this is that in 
both adminUI and the new console browsing of groups contents requires a 
slightly higher privilege. Previously we had a very detailed filtering 
of data returned for role of inspector. Now it was simplified, and while 
authorization works in the same way (i.e. Inspector can access the same 
data it could before) it is not enough to use Console UI/Admin UI which 
are using simplier API for performance. We could also support the 
original Inspector role, but it would require a separate optimized 
implementation and at the same time we believe that AdminUI/Console 
should be rather used by privileged users.

The solution is quite straightforward: the "Privileged inspector" role 
has enough capabilities to use console/adminUI in RO mode, so use it for 
RO users of Console/AdminUI. The "Inspector" role is still useful as a 
more limited user on REST API. The difference between the two roles is 
that Privileged inspector can read also some of the data "hidden" from 
outside world, like disabled entities, which are not shown to the plain 
"Inspector".

HTH,
Krzysztof

[Unity-idm-discuss] Inspector is not authorized to read members in unity 2.8.2

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

Dear Krzysztof,

we have some users who has Inspector privileges. Since we updated to
unity 2.8.2 this users got the error "Not authorized to read members of
the group" when they try to view the users in admin endpoint. Was this
changed behaviour planed?

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,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Theme issue with remote IdPs

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

Hi Sander,

W dniu 17.12.2019 o 09:01, Sander Apweiler pisze:
> Hi Krzysztof,
>
> We found an issue within the remembered remote IdP. The text of the IdP
> is longer than the button. I attached a screenshot of it. I also add
> another screenshot from a different theme where text and general
> background colours differ. We found this issue in unity 2.8.2 and also
> in 3.x releases. Because we skipped 2.6 and 2.7 I don't know if the
> issues was there too.


In general I think you want to have wider column with your authN 
options. If you have a single one or even two, this shouldn't be a 
problem - that's trivial to fix in console or for 2.8 in config file.
Also you can modify your style to have more narrow font if you find this 
a problem.

Finally you can add this to your style for the .u-externalSignInButton 
class:

overflow: hidden;
text-overflow: ellipsis;

-> then text will be cut. I'll also add this to our default style.

overflow: hidden;
text-overflow: ellipsis;

[Unity-idm-discuss] Theme issue with remote IdPs

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

Hi Krzysztof,

We found an issue within the remembered remote IdP. The text of the IdP
is longer than the button. I attached a screenshot of it. I also add
another screenshot from a different theme where text and general
background colours differ. We found this issue in unity 2.8.2 and also
in 3.x releases. Because we skipped 2.6 and 2.7 I don't know if the
issues was there too.

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,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

[Unity-idm-discuss] Unity 3.1.3 is released

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

Dear Subscribers,


Soon after previous release we have a subsequent patch release out: 3.1.3.

It fixes couple of issues which happen in rather corner cases, but are 
rather problematic.

Detailed changelog is available at 
https://www.unity-idm.eu/downloads/#1546947302140-1b56c81b-46d9

Best regards,
Krzysztof

Re: [Unity-idm-discuss] NullPointer in admin endpoint after update to unity 3.1.1

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

Hi Sander,

W dniu 13.12.2019 o 08:55, Sander Apweiler pisze:
> Dear Krzysztof,
>
> we started to test unity 3.1.1. After the deployment the webadmin
> endpoint throws a null pointer exception (log is attached). The
> exception is raised after the authentication is finished and the
> content should be loaded. Was there an additional change in the config?

I think I understand what happened. I guess you was upgrading from 2.8.x 
to 3.1 via DB update. Is this correct? Assuming yes, we had a breaking 
change in internal representation of OAuth tokens, introduced in 3.0. 
There was no migration for it, as at the time this change was applied 
those tokens were wiped during migration. But at the same time (almost, 
actually bit after this change) we decided that oauth tokens (and all 
other) should not be wiped during migration. This is now implemented for 
DB upgrade and also for JSON migration since 3.1. But we havn't go back 
and write a migration for OAuth tokens, which started to be necessary 
after this change.

I'll prepare a hotfix migration in 3.1.3 to correct this behavior, which 
will be released very soon.

Thanks,
Krzysztof

[Unity-idm-discuss] NullPointer in admin endpoint after update to unity 3.1.1

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

Dear Krzysztof,

we started to test unity 3.1.1. After the deployment the webadmin
endpoint throws a null pointer exception (log is attached). The
exception is raised after the authentication is finished and the
content should be loaded. Was there an additional change in the config?

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,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] issue with certificates after updating unity from 2.4.2 to 2.8.2

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

Dear Krzysztof,

sorry for the noise, but I found the reason for it. Unity still uses
the Grid certificate infrastructure. The problem was that the user used
and outdated certificate. In past it worked for the SSL handshake but
now it does not work for the SSL handshake anymore. Using a valid Grid
certificate works.

The change is positive, but for (stupid) users it looks like the
services has an error.

Best regards,
Sander

On Thu, 2019-12-12 at 13:04 +0100, Sander Apweiler wrote:
> Dear Krzysztof,
> 
> I updated unity from 2.4.2 to 2.8.2. I know that this version is old
> too. But we are not ready to update to unity 3.
> 
> After the update I have an issue with certificates.
> 
> If you select a grid certificate for authentication, it is rejected
> and
> you get a "Secure Connection Failed" error with "SSL peer had some
> unspecified issue with the certificate it received." It seems that
> unity does not like the Grid cert infrastructure any more. When I use
> a
> global certificate everything went well.
> 
> The pki truststore config is the same like in 2.4.2:
> unity.pki.truststores.MAIN.type=directory
> unity.pki.truststores.MAIN.allowProxy=DENY
> unity.pki.truststores.MAIN.directoryLocations.1=/usr/local/unity/cert
> s/*
> unity.pki.truststores.MAIN.directoryLocations.2=/etc/grid-
> security/certificates/*.pem
> unity.pki.truststores.MAIN.crlLocations.1=/etc/grid-
> security/certificates/*.crl
> unity.pki.truststores.MAIN.directoryEncoding=PEM
> unity.pki.truststores.MAIN.crlUpdateInterval=400
> 
> unity.pki.truststores.WEB.type=directory
> unity.pki.truststores.WEB.allowProxy=DENY
> unity.pki.truststores.WEB.directoryLocations.1=/usr/local/unity/certs
> /*
> unity.pki.truststores.WEB.crlLocations.1=/etc/grid-
> security/certificates/*.crl
> unity.pki.truststores.WEB.directoryEncoding=PEM
> unity.pki.truststores.WEB.crlUpdateInterval=400
> 
> The authenticator configuration in unityServer.conf was adjusted to
> have only one single certificate configuration:
> unityServer.core.authenticators.cert.authenticatorName=cert
> unityServer.core.authenticators.cert.authenticatorType=certificate
> unityServer.core.authenticators.cert.localCredential=Certificate
> credential
> unityServer.core.authenticators.cert.configurationFile=${CONF}/authen
> ticators/certificateRetrieval.properties
> 
> Do you have any clue why it is not working anymore? There is no error
> in the logs about it.
> 
> 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,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------