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