unity-idm-discuss — Unity discussion and support

Re: [Unity-idm-discuss] Requesting token audience

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

On 21. Feb 2022 11:53, Krzysztof Benedyczak wrote:
> Gents,
> 
> As we have 2 topics here let me break the thread into two.

Many thanks (I was shocked by seeing the length of the email).
 
> Here audience goes
> W dniu 21.02.2022 o 11:42, Sander Apweiler pisze:
> > Good morning Krzysztof,
> > I'm sorry for the delay. There were a lot of meetings end of last week
> > and I had no time answer earlier.
> > 
> > On Thu, 2022-02-17 at 10:16 +0100, Marcus Hardt wrote:
> > > On 16. Feb 2022 23:03, Krzysztof Benedyczak wrote:
> > > > Hi Sander,
> > > > 
> > > > let me ask for few clarifications.
> > > > 
> > > > W dniu 15.02.2022 o 15:26, Sander Apweiler pisze:
> > > > > Hello Krzysztof,
> > > > > hello Roman,
> > > > > 
> > > > > since our connected SPs are growing we do get further feature
> > > > > request,
> > > > > which I want to share with you.
> > > > > 
> > > > > The first one is a possibility to change the aud of a registered
> > > > > client. At the moment unity uses the registered username of the
> > > > > OIDC
> > > > > client, which is fine according to the RFC. But there are
> > > > > connected
> > > > > services which does the audience use, too. In this specific use-
> > > > > case
> > > > > the token was generated by the user using the oidc-agent tool
> > > > > [1]. The
> > > > > generated token was send via an API to dCache which validates the
> > > > > token. dCache is also checking the audience and rejects all token
> > > > > having an unsupported audience. The OIDC agent has an option the
> > > > > request a specific aud value for the token and forwards this
> > > > > request to
> > > > > the AS. Together with the request users showed us examples where
> > > > > Indigo
> > > > > IAM do support this. Would it possible to implement this unity,
> > > > > too?
> > > > So for the support of multiple audiences per client - certainly
> > > > that's
> > > > possible. I understand that this is just a configuration of allowed
> > > > additional audiences. Each of such audience should have its
> > > > identifier and
> > > > have to be returned. Easy.
> > > > 
> > > > Can you tell more what is the purpose of "requesting" of a specific
> > > > audience
> > > > by the client? I think it is some proprietary feature of Indigo
> > > > IAM. We can
> > > > have it, but sounds like a bigger work, and I need to understand
> > > > the purpose
> > > > and details of the use case. Also, technically, would that be just
> > > > narrowing
> > > > of the allowed audiences of the client? Shall that be then also
> > > > presented on
> > > > consent screen?
> > > > 
> > > > The aud claim is a bit weird.
> > > > 
> > > > In the oidc core spec I find it mostly in the ID Token, where "it
> > > > MUST
> > > > contain the OAuth 2.0 client_id".
> > > > 
> > > > It does make sense to be mandatory, and to be the client_id for the
> > > > ID
> > > > Token, because the ID Token is for that specific client_id only.
> > > > 
> > > > 
> > > > The aud claim is also used in JWT ATs, and therein became mandatory
> > > > via
> > > > RFC9068[1] / RFC7519[2]. Just: The notion of the client_id isn't
> > > > there,
> > > > because ATs may also be intended for others than only a specific
> > > > client_id.
> > > > [1] https://www.rfc-editor.org/rfc/rfc9068#name-data-structure
> > > > [2] https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3
> > > > 
> > > > This lead the WLCG people to use it for their purposes [3]
> > > > [3] https://zenodo.org/record/3460258
> > > > 
> > > > Funny enough, [3] states
> > > > 
> > > >      The contents of the claim may either be a string or URL; we do
> > > > not
> > > >      currently provide specific guidance on selecting audience names.
> > > > 
> > > > Also, they forget to mention that it's a JSON list, not a space
> > > > separated
> > > > list of strings.
> > > > 
> > > > 
> > > > By now, people started using it for different ways to specify who
> > > > should
> > > > use the token.  dCache is already tokens that it considers not
> > > > intended
> > > > for itself.
> > > > 
> > > > With the WLCG profile of Indigo-IAM this works "well".
> > > > 
> > > > 
> > > > With oidc-agent we simply allow users to specify what they want to
> > > > have in
> > > > the token.
> > > > 
> > > > In the lack of an existing spec, oidc-agent first implemented
> > > > something IAM
> > > > specific, and will move to useing RFC8707[4] to request specific
> > > > scopes.
> > > > [4] https://www.rfc-editor.org/rfc/rfc8707
> > > > 
> > > > 
> > Beside the specification hints from Marcus and the background for
> > implementing it in oidc-agent, I just can add that we had request from
> > different service providers, I guess all of them knows Indigo IAM, if
> > we could make the aud claim adjustable because they do want to limit
> > token acceptance to tokens which contain their service in the aud
> > claim. But all of this services are using command line and tokens which
> > was collected e.g. using oidc-agent.
> 
> @Marcus all you wrote is consistent with my understanding, however thanks
> for the RFC8707 link - I was missing that.
> 
> Having that the situation is much more clear: the request is to implement
> that RFC.
> 
> My doubts are around two aspects here:
> 
> 1. shall we have the allowed audiences preregistered per-client (or
> authorization server endpoint) in Unity? This will allow for control of
> which audiences are in general allowed for client as well as to present them
> in readable form on consent screen. -> My current thinking here is: no, that
> can be done later if/when needed.

Yes, I think I was this is what is also sometimes done for the allowed
scopes per client. But a) I'm not sure if there is (already) a valid use
case for this, and b) it causes more pain to the client registration
process.
Add-on-demand seems ideal.
 
> 2. shall we present requested audiences on consent screen? -> My thinking
> here is: yes, we should. Actually currently audience is restricted to the
> client itself, which can use the token on other services only if those
> services ignore audience claim. So if Unity will "officially" allow for
> additional audiences, it shoud inform about that.

Yes, that probably makes sense too (although, judging from myself, the
consent screen hardly receives the attention that it should).

-- 
Marcus.

Re: [Unity-idm-discuss] Claims in id token

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

And here the remaining part of the original thread, related to extra 
claims in id/access tokens.

W dniu 21.02.2022 o 11:42, Sander Apweiler pisze:
>>>> The second request we got is about user attributes within the
>>>> token.
>>>> The user, who made the request told us that the targeted software
>>>> does
>>>> not support requests to userinfo endpoint and does not keep
>>>> consistent
>>>> information about the user. For this they need information about
>>>> the
>>>> user in the token itself. I got the friendly hint that WLCG does
>>>> it in
>>>> this way. We already talked in the past about the possibility to
>>>> add
>>>> own claims. Maybe the better solution would be supporting the
>>>> request
>>>> parameter to allow SPs to request the needed claims itself
>>>> instead of
>>>> adding some claims in general. Would this be an option for unity?
>>> We have a ticket on that already recorded, and is on the top of
>>> open source
>>> queue.
>>>
>>> Although we understand this bit differently. We were thinking about
>>> server-side controlled setting to include some of the claims
>>> (attributes) in
>>> the id token (applies to oidc mode only). Perhaps configured per
>>> scope (as
>>> we have attributes bound to scopes).
>>>
>>> Putting client in control of that sounds as a bit of an overkill.
>>> Especially
>>> if you want to allow client to pick and choose which individual
>>> attributesshould go into id token. Is there a strong use case for
>>> that?
>> I guess this goes a bit like the scopes clients can request to be
>> available in the userinfo endpoint.
>>
>> The current headache this brings up for the AccessTokens is that we
>> have
>> two compeing use cases. One would like to have all authorisation
>> statements inside the token, so it never ever needs to contact the
>> OP,
>> while the other needs tokens below the 1k limit.
>>
>> Both of these use cases can be asked to work around this. I don't
>> have a
>> strong opinion here.
> I guess the first ticket was also initiated by me. The first Idea was
> to have it under server control, because it was "only" groupmembership
> information which was needed by some services. In meantime other
> services requests other attributes in the access token.
>
> Putting more information in the AT, the large size of it creates
> problems for some other service. For this reason we do not want to put
> to many additional attributes in the AT. In the best case only the
> attributes which are needed by the specific service. For this the
> services need a way to signal it to unity. Of course the unity
> administrators must be able to limit/configure which attributes could
> be released within the AT.
>
> I don't know if the specification contains something about this. If not
> hinting the needed attributes in the token via specific scopes might be
> a way.

Well, so it seems we have a small confusion. Id token, or JWT access token?

For the other part of the question, i.e. how to request and or configure 
it seems that this is strongly client-specific. So why not tho have this 
switch per-client? Sounds as the easiest way forward.

Configuration with scopes would also work, but would require more dev 
work, and then more configuration (admin would need to double number of 
scopes, to have variants with a thin token, or fully packed.

WDYT?

Krzysztof

Re: [Unity-idm-discuss] Requesting token audience

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

Gents,

As we have 2 topics here let me break the thread into two.

Here audience goes
W dniu 21.02.2022 o 11:42, Sander Apweiler pisze:
> Good morning Krzysztof,
> I'm sorry for the delay. There were a lot of meetings end of last week
> and I had no time answer earlier.
>
> On Thu, 2022-02-17 at 10:16 +0100, Marcus Hardt wrote:
>> On 16. Feb 2022 23:03, Krzysztof Benedyczak wrote:
>>> Hi Sander,
>>>
>>> let me ask for few clarifications.
>>>
>>> W dniu 15.02.2022 o 15:26, Sander Apweiler pisze:
>>>> Hello Krzysztof,
>>>> hello Roman,
>>>>
>>>> since our connected SPs are growing we do get further feature
>>>> request,
>>>> which I want to share with you.
>>>>
>>>> The first one is a possibility to change the aud of a registered
>>>> client. At the moment unity uses the registered username of the
>>>> OIDC
>>>> client, which is fine according to the RFC. But there are
>>>> connected
>>>> services which does the audience use, too. In this specific use-
>>>> case
>>>> the token was generated by the user using the oidc-agent tool
>>>> [1]. The
>>>> generated token was send via an API to dCache which validates the
>>>> token. dCache is also checking the audience and rejects all token
>>>> having an unsupported audience. The OIDC agent has an option the
>>>> request a specific aud value for the token and forwards this
>>>> request to
>>>> the AS. Together with the request users showed us examples where
>>>> Indigo
>>>> IAM do support this. Would it possible to implement this unity,
>>>> too?
>>> So for the support of multiple audiences per client - certainly
>>> that's
>>> possible. I understand that this is just a configuration of allowed
>>> additional audiences. Each of such audience should have its
>>> identifier and
>>> have to be returned. Easy.
>>>
>>> Can you tell more what is the purpose of "requesting" of a specific
>>> audience
>>> by the client? I think it is some proprietary feature of Indigo
>>> IAM. We can
>>> have it, but sounds like a bigger work, and I need to understand
>>> the purpose
>>> and details of the use case. Also, technically, would that be just
>>> narrowing
>>> of the allowed audiences of the client? Shall that be then also
>>> presented on
>>> consent screen?
>>>
>>> The aud claim is a bit weird.
>>>
>>> In the oidc core spec I find it mostly in the ID Token, where "it
>>> MUST
>>> contain the OAuth 2.0 client_id".
>>>
>>> It does make sense to be mandatory, and to be the client_id for the
>>> ID
>>> Token, because the ID Token is for that specific client_id only.
>>>
>>>
>>> The aud claim is also used in JWT ATs, and therein became mandatory
>>> via
>>> RFC9068[1] / RFC7519[2]. Just: The notion of the client_id isn't
>>> there,
>>> because ATs may also be intended for others than only a specific
>>> client_id.
>>> [1] https://www.rfc-editor.org/rfc/rfc9068#name-data-structure
>>> [2] https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3
>>>
>>> This lead the WLCG people to use it for their purposes [3]
>>> [3] https://zenodo.org/record/3460258
>>>
>>> Funny enough, [3] states
>>>
>>>      The contents of the claim may either be a string or URL; we do
>>> not
>>>      currently provide specific guidance on selecting audience names.
>>>
>>> Also, they forget to mention that it's a JSON list, not a space
>>> separated
>>> list of strings.
>>>
>>>
>>> By now, people started using it for different ways to specify who
>>> should
>>> use the token.  dCache is already tokens that it considers not
>>> intended
>>> for itself.
>>>
>>> With the WLCG profile of Indigo-IAM this works "well".
>>>
>>>
>>> With oidc-agent we simply allow users to specify what they want to
>>> have in
>>> the token.
>>>
>>> In the lack of an existing spec, oidc-agent first implemented
>>> something IAM
>>> specific, and will move to useing RFC8707[4] to request specific
>>> scopes.
>>> [4] https://www.rfc-editor.org/rfc/rfc8707
>>>
>>>
> Beside the specification hints from Marcus and the background for
> implementing it in oidc-agent, I just can add that we had request from
> different service providers, I guess all of them knows Indigo IAM, if
> we could make the aud claim adjustable because they do want to limit
> token acceptance to tokens which contain their service in the aud
> claim. But all of this services are using command line and tokens which
> was collected e.g. using oidc-agent.

@Marcus all you wrote is consistent with my understanding, however 
thanks for the RFC8707 link - I was missing that.

Having that the situation is much more clear: the request is to 
implement that RFC.

My doubts are around two aspects here:

1. shall we have the allowed audiences preregistered per-client (or 
authorization server endpoint) in Unity? This will allow for control of 
which audiences are in general allowed for client as well as to present 
them in readable form on consent screen. -> My current thinking here is: 
no, that can be done later if/when needed.

2. shall we present requested audiences on consent screen? -> My 
thinking here is: yes, we should. Actually currently audience is 
restricted to the client itself, which can use the token on other 
services only if those services ignore audience claim. So if Unity will 
"officially" allow for additional audiences, it shoud inform about that.

Does it make sense for you?

Best,
Krzysztof

Re: [Unity-idm-discuss] Addition to OAuth2/OIDC tokens

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

Good morning Krzysztof,
I'm sorry for the delay. There were a lot of meetings end of last week
and I had no time answer earlier.

On Thu, 2022-02-17 at 10:16 +0100, Marcus Hardt wrote:
> On 16. Feb 2022 23:03, Krzysztof Benedyczak wrote:
> > Hi Sander,
> > 
> > let me ask for few clarifications.
> > 
> > W dniu 15.02.2022 o 15:26, Sander Apweiler pisze:
> > > Hello Krzysztof,
> > > hello Roman,
> > > 
> > > since our connected SPs are growing we do get further feature
> > > request,
> > > which I want to share with you.
> > > 
> > > The first one is a possibility to change the aud of a registered
> > > client. At the moment unity uses the registered username of the
> > > OIDC
> > > client, which is fine according to the RFC. But there are
> > > connected
> > > services which does the audience use, too. In this specific use-
> > > case
> > > the token was generated by the user using the oidc-agent tool
> > > [1]. The
> > > generated token was send via an API to dCache which validates the
> > > token. dCache is also checking the audience and rejects all token
> > > having an unsupported audience. The OIDC agent has an option the
> > > request a specific aud value for the token and forwards this
> > > request to
> > > the AS. Together with the request users showed us examples where
> > > Indigo
> > > IAM do support this. Would it possible to implement this unity,
> > > too?
> > 
> > So for the support of multiple audiences per client - certainly
> > that's
> > possible. I understand that this is just a configuration of allowed
> > additional audiences. Each of such audience should have its
> > identifier and
> > have to be returned. Easy.
> > 
> > Can you tell more what is the purpose of "requesting" of a specific
> > audience
> > by the client? I think it is some proprietary feature of Indigo
> > IAM. We can
> > have it, but sounds like a bigger work, and I need to understand
> > the purpose
> > and details of the use case. Also, technically, would that be just
> > narrowing
> > of the allowed audiences of the client? Shall that be then also
> > presented on
> > consent screen?
> 
> The aud claim is a bit weird.
> 
> In the oidc core spec I find it mostly in the ID Token, where "it
> MUST
> contain the OAuth 2.0 client_id".
> 
> It does make sense to be mandatory, and to be the client_id for the
> ID
> Token, because the ID Token is for that specific client_id only.
> 
> 
> The aud claim is also used in JWT ATs, and therein became mandatory
> via
> RFC9068[1] / RFC7519[2]. Just: The notion of the client_id isn't
> there,
> because ATs may also be intended for others than only a specific
> client_id. 
> [1] https://www.rfc-editor.org/rfc/rfc9068#name-data-structure
> [2] https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3
> 
> This lead the WLCG people to use it for their purposes [3]
> [3] https://zenodo.org/record/3460258
> 
> Funny enough, [3] states 
> 
>     The contents of the claim may either be a string or URL; we do
> not
>     currently provide specific guidance on selecting audience names.
> 
> Also, they forget to mention that it's a JSON list, not a space
> separated
> list of strings.
> 
> 
> By now, people started using it for different ways to specify who
> should
> use the token.  dCache is already tokens that it considers not
> intended
> for itself.
> 
> With the WLCG profile of Indigo-IAM this works "well".
> 
> 
> With oidc-agent we simply allow users to specify what they want to
> have in
> the token.
> 
> In the lack of an existing spec, oidc-agent first implemented
> something IAM
> specific, and will move to useing RFC8707[4] to request specific
> scopes.
> [4] https://www.rfc-editor.org/rfc/rfc8707
> 
> 
Beside the specification hints from Marcus and the background for
implementing it in oidc-agent, I just can add that we had request from
different service providers, I guess all of them knows Indigo IAM, if
we could make the aud claim adjustable because they do want to limit
token acceptance to tokens which contain their service in the aud
claim. But all of this services are using command line and tokens which
was collected e.g. using oidc-agent.
>  
> > > The second request we got is about user attributes within the
> > > token.
> > > The user, who made the request told us that the targeted software
> > > does
> > > not support requests to userinfo endpoint and does not keep
> > > consistent
> > > information about the user. For this they need information about
> > > the
> > > user in the token itself. I got the friendly hint that WLCG does
> > > it in
> > > this way. We already talked in the past about the possibility to
> > > add
> > > own claims. Maybe the better solution would be supporting the
> > > request
> > > parameter to allow SPs to request the needed claims itself
> > > instead of
> > > adding some claims in general. Would this be an option for unity?
> > 
> > We have a ticket on that already recorded, and is on the top of
> > open source
> > queue.
> > 
> > Although we understand this bit differently. We were thinking about
> > server-side controlled setting to include some of the claims
> > (attributes) in
> > the id token (applies to oidc mode only). Perhaps configured per
> > scope (as
> > we have attributes bound to scopes).
> > 
> > Putting client in control of that sounds as a bit of an overkill.
> > Especially
> > if you want to allow client to pick and choose which individual
> > attributesshould go into id token. Is there a strong use case for
> > that?
> 
> I guess this goes a bit like the scopes clients can request to be
> available in the userinfo endpoint.
> 
> The current headache this brings up for the AccessTokens is that we
> have
> two compeing use cases. One would like to have all authorisation
> statements inside the token, so it never ever needs to contact the
> OP,
> while the other needs tokens below the 1k limit.
> 
> Both of these use cases can be asked to work around this. I don't
> have a
> strong opinion here.

I guess the first ticket was also initiated by me. The first Idea was
to have it under server control, because it was "only" groupmembership
information which was needed by some services. In meantime other
services requests other attributes in the access token.

Putting more information in the AT, the large size of it creates
problems for some other service. For this reason we do not want to put
to many additional attributes in the AT. In the best case only the
attributes which are needed by the specific service. For this the
services need a way to signal it to unity. Of course the unity
administrators must be able to limit/configure which attributes could
be released within the AT.

I don't know if the specification contains something about this. If not
hinting the needed attributes in the token via specific scopes might be
a way.

Best regards,
Sander
> 
> _______________________________________________
> Unity-idm-discuss mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss

-- 
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. Astrid Lambrecht,
Prof. Dr. Frauke Melchior
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Addition to OAuth2/OIDC tokens

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

On 16. Feb 2022 23:03, Krzysztof Benedyczak wrote:
> Hi Sander,
> 
> let me ask for few clarifications.
> 
> W dniu 15.02.2022 o 15:26, Sander Apweiler pisze:
> > Hello Krzysztof,
> > hello Roman,
> > 
> > since our connected SPs are growing we do get further feature request,
> > which I want to share with you.
> > 
> > The first one is a possibility to change the aud of a registered
> > client. At the moment unity uses the registered username of the OIDC
> > client, which is fine according to the RFC. But there are connected
> > services which does the audience use, too. In this specific use-case
> > the token was generated by the user using the oidc-agent tool [1]. The
> > generated token was send via an API to dCache which validates the
> > token. dCache is also checking the audience and rejects all token
> > having an unsupported audience. The OIDC agent has an option the
> > request a specific aud value for the token and forwards this request to
> > the AS. Together with the request users showed us examples where Indigo
> > IAM do support this. Would it possible to implement this unity, too?
> 
> So for the support of multiple audiences per client - certainly that's
> possible. I understand that this is just a configuration of allowed
> additional audiences. Each of such audience should have its identifier and
> have to be returned. Easy.
> 
> Can you tell more what is the purpose of "requesting" of a specific audience
> by the client? I think it is some proprietary feature of Indigo IAM. We can
> have it, but sounds like a bigger work, and I need to understand the purpose
> and details of the use case. Also, technically, would that be just narrowing
> of the allowed audiences of the client? Shall that be then also presented on
> consent screen?

The aud claim is a bit weird.

In the oidc core spec I find it mostly in the ID Token, where "it MUST
contain the OAuth 2.0 client_id".

It does make sense to be mandatory, and to be the client_id for the ID
Token, because the ID Token is for that specific client_id only.


The aud claim is also used in JWT ATs, and therein became mandatory via
RFC9068[1] / RFC7519[2]. Just: The notion of the client_id isn't there,
because ATs may also be intended for others than only a specific
client_id. 
[1] https://www.rfc-editor.org/rfc/rfc9068#name-data-structure
[2] https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3

This lead the WLCG people to use it for their purposes [3]
[3] https://zenodo.org/record/3460258

Funny enough, [3] states 

    The contents of the claim may either be a string or URL; we do not
    currently provide specific guidance on selecting audience names.

Also, they forget to mention that it's a JSON list, not a space separated
list of strings.


By now, people started using it for different ways to specify who should
use the token.  dCache is already tokens that it considers not intended
for itself.

With the WLCG profile of Indigo-IAM this works "well".


With oidc-agent we simply allow users to specify what they want to have in
the token.

In the lack of an existing spec, oidc-agent first implemented something IAM
specific, and will move to useing RFC8707[4] to request specific scopes.
[4] https://www.rfc-editor.org/rfc/rfc8707


 
> > The second request we got is about user attributes within the token.
> > The user, who made the request told us that the targeted software does
> > not support requests to userinfo endpoint and does not keep consistent
> > information about the user. For this they need information about the
> > user in the token itself. I got the friendly hint that WLCG does it in
> > this way. We already talked in the past about the possibility to add
> > own claims. Maybe the better solution would be supporting the request
> > parameter to allow SPs to request the needed claims itself instead of
> > adding some claims in general. Would this be an option for unity?
> 
> We have a ticket on that already recorded, and is on the top of open source
> queue.
> 
> Although we understand this bit differently. We were thinking about
> server-side controlled setting to include some of the claims (attributes) in
> the id token (applies to oidc mode only). Perhaps configured per scope (as
> we have attributes bound to scopes).
> 
> Putting client in control of that sounds as a bit of an overkill. Especially
> if you want to allow client to pick and choose which individual
> attributesshould go into id token. Is there a strong use case for that?

I guess this goes a bit like the scopes clients can request to be
available in the userinfo endpoint.

The current headache this brings up for the AccessTokens is that we have
two compeing use cases. One would like to have all authorisation
statements inside the token, so it never ever needs to contact the OP,
while the other needs tokens below the 1k limit.

Both of these use cases can be asked to work around this. I don't have a
strong opinion here.

-- 
Marcus.

Re: [Unity-idm-discuss] Addition to OAuth2/OIDC tokens

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

Hi Sander,

let me ask for few clarifications.

W dniu 15.02.2022 o 15:26, Sander Apweiler pisze:
> Hello Krzysztof,
> hello Roman,
>
> since our connected SPs are growing we do get further feature request,
> which I want to share with you.
>
> The first one is a possibility to change the aud of a registered
> client. At the moment unity uses the registered username of the OIDC
> client, which is fine according to the RFC. But there are connected
> services which does the audience use, too. In this specific use-case
> the token was generated by the user using the oidc-agent tool [1]. The
> generated token was send via an API to dCache which validates the
> token. dCache is also checking the audience and rejects all token
> having an unsupported audience. The OIDC agent has an option the
> request a specific aud value for the token and forwards this request to
> the AS. Together with the request users showed us examples where Indigo
> IAM do support this. Would it possible to implement this unity, too?

So for the support of multiple audiences per client - certainly that's 
possible. I understand that this is just a configuration of allowed 
additional audiences. Each of such audience should have its identifier 
and have to be returned. Easy.

Can you tell more what is the purpose of "requesting" of a specific 
audience by the client? I think it is some proprietary feature of Indigo 
IAM. We can have it, but sounds like a bigger work, and I need to 
understand the purpose and details of the use case. Also, technically, 
would that be just narrowing of the allowed audiences of the client? 
Shall that be then also presented on consent screen?


> The second request we got is about user attributes within the token.
> The user, who made the request told us that the targeted software does
> not support requests to userinfo endpoint and does not keep consistent
> information about the user. For this they need information about the
> user in the token itself. I got the friendly hint that WLCG does it in
> this way. We already talked in the past about the possibility to add
> own claims. Maybe the better solution would be supporting the request
> parameter to allow SPs to request the needed claims itself instead of
> adding some claims in general. Would this be an option for unity?

We have a ticket on that already recorded, and is on the top of open 
source queue.

Although we understand this bit differently. We were thinking about 
server-side controlled setting to include some of the claims 
(attributes) in the id token (applies to oidc mode only). Perhaps 
configured per scope (as we have attributes bound to scopes).

Putting client in control of that sounds as a bit of an overkill. 
Especially if you want to allow client to pick and choose which 
individual attributesshould go into id token. Is there a strong use case 
for that?

Best,
Krzysztof

[Unity-idm-discuss] Addition to OAuth2/OIDC tokens

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

Hello Krzysztof,
hello Roman,

since our connected SPs are growing we do get further feature request,
which I want to share with you.

The first one is a possibility to change the aud of a registered
client. At the moment unity uses the registered username of the OIDC
client, which is fine according to the RFC. But there are connected
services which does the audience use, too. In this specific use-case
the token was generated by the user using the oidc-agent tool [1]. The
generated token was send via an API to dCache which validates the
token. dCache is also checking the audience and rejects all token
having an unsupported audience. The OIDC agent has an option the
request a specific aud value for the token and forwards this request to
the AS. Together with the request users showed us examples where Indigo
IAM do support this. Would it possible to implement this unity, too?

The second request we got is about user attributes within the token.
The user, who made the request told us that the targeted software does
not support requests to userinfo endpoint and does not keep consistent
information about the user. For this they need information about the
user in the token itself. I got the friendly hint that WLCG does it in
this way. We already talked in the past about the possibility to add
own claims. Maybe the better solution would be supporting the request
parameter to allow SPs to request the needed claims itself instead of
adding some claims in general. Would this be an option for unity?

If you want we could discuss this request more detailed.

Best regards,
Sander

[1]: https://indigo-dc.gitbook.io/oidc-agent/

-- 
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. Astrid Lambrecht,
Prof. Dr. Frauke Melchior
-----------------------------------------------------------------------
-----------------------------------------------------------------------

[Unity-idm-discuss] Refresh of Unity web page

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

Dear Subscribers,

In the last days we have refreshed some important elements of the 
https://unity-idm.eu web page. Our primary goal was to automate web page 
update process after a new release is added.

The main changes are therefore in the new Releases page, which replaces 
the former Downloads page. It contains tiles representing individual 
releases, each release (even revision) has its own entry.

Each release page contains a fixed set of links in the right sidebar. 
The main link is Assets, which points to the corresponding GitHub 
release page, where you can find a detailed list of addressed tickets, 
all links to documentation as well as to downloads. Direct links to 
downloads and user manual are also available directly from release page 
on https://unity-idm.eu.

Note that legacy releases, earlier than 3.0.0, were not converted to 
this new scheme and are only available in an archive linked at the 
bottom of the all Releases web page.


Example release looks as follows:



Best regards,
Krzysztof

Re: [Unity-idm-discuss] credentials outdated screen not shown

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

Hi Sander,

W dniu 01.02.2022 o 12:56, Sander Apweiler pisze:
> Hi Krzysztof,
> we have an issue in unity 3.6.1. The outdated credential dialog is not
> shown, although it was launched. Maybe this might be an issue with the
> changed theme, but other pop-ups are shown.
>
> 2022-02-01T12:42:15,148 [qtp1640598380-1089] INFO
> unity.server.web.ColumnInstantAuthenticationScreen: Launched outdated
> credential dialog

https://unity-idm.atlassian.net/browse/UY-1184

fixed in 3.7.0

> Another question: Is it possible to set the password lifetime to
> infinite again?
>
Yes, why not? You can uncheck "require password change after some time" 
in password credential config and that's it.

Or you meant something other?

HTH,
Krzysztof

[Unity-idm-discuss] credentials outdated screen not shown

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

Hi Krzysztof,
we have an issue in unity 3.6.1. The outdated credential dialog is not
shown, although it was launched. Maybe this might be an issue with the
changed theme, but other pop-ups are shown.

2022-02-01T12:42:15,148 [qtp1640598380-1089] INFO 
unity.server.web.ColumnInstantAuthenticationScreen: Launched outdated
credential dialog

Another question: Is it possible to set the password lifetime to
infinite again?

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. Astrid Lambrecht,
Prof. Dr. Frauke Melchior
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Link upman endpoint to specific userhome

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

Thanks for the swift response.

Best regards,
Sander

On Mon, 2022-01-31 at 13:57 +0100, Krzysztof Benedyczak wrote:
> Hi,
> 
> W dniu 31.01.2022 o 13:10, Sander Apweiler pisze:
> > Hi Krzysztof,
> > I know I can link userhome endpoint to a specific upman endpoint
> > using
> > unity.userhome.projectManagementEndpoint but is there a parameter
> > to
> > link upman to userhome as well? Section 14.8 does not show some
> > parameters for this link.
> 
> Ups, seems we don't put upman's config reference in manual. So yes,
> this 
> is supported, those are the options:
> 
> unity.upman.enableHomeLink
> 
> unity.upman.homeEndpoint
> 
> (same usage as unity.userhome.enableProjectManagementLink and 
> unity.userhome.projectManagementEndpoint but in other direction)
> 
> We will add that to manual.
> 
> 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. Astrid Lambrecht,
Prof. Dr. Frauke Melchior
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Link upman endpoint to specific userhome

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

Hi,

W dniu 31.01.2022 o 13:10, Sander Apweiler pisze:
> Hi Krzysztof,
> I know I can link userhome endpoint to a specific upman endpoint using
> unity.userhome.projectManagementEndpoint but is there a parameter to
> link upman to userhome as well? Section 14.8 does not show some
> parameters for this link.

Ups, seems we don't put upman's config reference in manual. So yes, this 
is supported, those are the options:

unity.upman.enableHomeLink

unity.upman.homeEndpoint

(same usage as unity.userhome.enableProjectManagementLink and 
unity.userhome.projectManagementEndpoint but in other direction)

We will add that to manual.

Cheers,
Krzysztof

[Unity-idm-discuss] Link upman endpoint to specific userhome

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

Hi Krzysztof,
I know I can link userhome endpoint to a specific upman endpoint using
unity.userhome.projectManagementEndpoint but is there a parameter to
link upman to userhome as well? Section 14.8 does not show some
parameters for this link.

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. Astrid Lambrecht,
Prof. Dr. Frauke Melchior
-----------------------------------------------------------------------
-----------------------------------------------------------------------

[Unity-idm-discuss] Unity release 3.8.1

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

Dear Subscribers,

In this patch release we are addressing three issues, out of which two 
are important:

  * Unity OAuth AS stopped to operate properly in the latest Firefox –
    v95. Authentication against Unity works fine, but troubles begin if
    user hits refresh or back button in her web browser, after
    authenticating against Unity Oauth AS. In this version we have added
    a workaround for that problem (which we are still trying to
    understand – it may be a bug in newly introduced 'fission' feature
    of FF).
  * We have fixed significantly too slow memory reclaiming of remote
    authentications (both completed successfully and unfinished). This
    fix should noticeable decrease memory consumption on instances using
    remote SAML authenticator within large federation. In future we are
    going to improve memory efficiency in this aspect significantly more.

More details in Downloads <https://www.unity-idm.eu/downloads/>.

Best regards,
Krzysztof

Re: [Unity-idm-discuss] Unity admin interface password lost

[Fernandez R. D. <dan...@ep...>]

Dear Krzysztof,


thanks a lot for your suggestion. That did the trick! I was able to create a new admin user and use that one to login.

Now I gained back control over my Unity instance.


Thanks a lot!!

Daniel.

________________________________
From: Krzysztof Benedyczak <kb...@un...>
Sent: Friday, January 14, 2022 9:52:58 AM
To: Fernandez Rodriguez Daniel; uni...@li...
Subject: Re: [Unity-idm-discuss] Unity admin interface password lost

Dear Daniel,

W dniu 13.01.2022 o 15:39, Fernandez Rodriguez Daniel via Unity-idm-discuss pisze:

Dear Unity admins,


my name is Daniel Fernandez.

A few werks ago, I inherited a working Unicore/Unity deployment. Unfortunately its configuration is not documented AT ALL and the person who configured it left the company some time ago...

I would like to login into the UNITY administration interface but unfortunately I don't have the admin password.
Is there a way I can reset the password for the admin user? I have full access to the server and the H2 database files.

I tried to connect to the H2 database with the user 'sa' (same password) but it did not work..
We are running Unity 2.6.2 version.

Ouch, that's an old instance. Set those two properties in unityServer.conf (also - worth trying if you still have those, whether the credentials from there work?):


unityServer.core.initialAdminUsername=my-new-admin-user
unityServer.core.initialAdminPassword=my-new-admin-pass


and restart. You have full reference here http://www.unity-idm.eu/documentation/unity-2.6.0/manual.html#configuration


That might not be all. Inspect logs carefully. In general you should have new user added with the above password. However there are two caveats:

1. (unlikely) the password you set need not to be super easy, might be rejected. The best is to use something random and longer than few chars.

2. (possible) the password will be assigned to a credential with id 'sys:password'. Now, your former admin could disable this credential from the authn options enabled on AdminUI. If that is the case you will have to add it in unityServer.conf (there should be authenticator using this credential + the authenticator needs to be enabled on AdminUI endpoint.


HTH,
Krzysztof

[Unity-idm-discuss] Unity 3.8.0 released

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

Dear Subscribers,

A new feature release 3.8.0 was published today. It brings huge number 
of improvements and couple of important bugfixes. The main highlights are:

  * Java 8 support dropped
  * Many OAuth enhancements: prompt param, offline_access scope,
    ui_locales param, standard compliant errors, no authN for public
    clients, and more
  * New remote IdP attribute introspection endpoint
  * Dropped support for Hazelcast
  * Multiple performance improvements on large setups

… and that’s by far not not all.

See Downloads <https://www.unity-idm.eu/downloads/> page for a detailed 
list of changes.

It is worth mentioning here that starting from the 3.8.0 release (or 
better said its planning phase) we have switched to a new tasks 
prioritization process. Thanks to that change, you will see much more of 
Community requests being addressed on a faster timeline. In particular, 
in the 3.8.0 release we have shipped 9 features requested by our Community.

Best regards,
Krzysztof

Re: [Unity-idm-discuss] Unity admin interface password lost

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

Dear Daniel,

W dniu 13.01.2022 o 15:39, Fernandez Rodriguez Daniel via 
Unity-idm-discuss pisze:
>
> Dear Unity admins,
>
>
> my name is Daniel Fernandez.
>
> A few werks ago, I inherited a working Unicore/Unity deployment. 
> Unfortunately its configuration is not documented AT ALL and the 
> person who configured it left the company some time ago...
>
> I would like to login into the UNITY administration interface but 
> unfortunately I don't have the admin password.
> Is there a way I can reset the password for the admin user? I have 
> full access to the server and the H2 database files.
>
> I tried to connect to the H2 database with the user 'sa' (same 
> password) but it did not work..
> We are running Unity 2.6.2 version.

Ouch, that's an old instance. Set those two properties in 
unityServer.conf (also - worth trying if you still have those, whether 
the credentials from there work?):


|unityServer.core.initialAdminUsername=my-new-admin-user|
||unityServer.core.initialAdminPassword=my-new-admin-pass||


and restart. You have full reference here 
http://www.unity-idm.eu/documentation/unity-2.6.0/manual.html#configuration


That might not be all. Inspect logs carefully. In general you should 
have new user added with the above password. However there are two caveats:

1. (unlikely) the password you set need not to be super easy, might be 
rejected. The best is to use something random and longer than few chars.

2. (possible) the password will be assigned to a credential with id 
'sys:password'. Now, your former admin could disable this credential 
from the authn options enabled on AdminUI. If that is the case you will 
have to add it in unityServer.conf (there should be authenticator using 
this credential + the authenticator needs to be enabled on AdminUI endpoint.


HTH,
Krzysztof

[Unity-idm-discuss] Unity admin interface password lost

[Fernandez R. D. <dan...@ep...>]

Dear Unity admins,


my name is Daniel Fernandez.

A few werks ago, I inherited a working Unicore/Unity deployment. Unfortunately its configuration is not documented AT ALL and the person who configured it left the company some time ago...

I would like to login into the UNITY administration interface but unfortunately I don't have the admin password.
Is there a way I can reset the password for the admin user? I have full access to the server and the H2 database files.

I tried to connect to the H2 database with the user 'sa' (same password) but it did not work..
We are running Unity 2.6.2 version.

Thank you very much for your help,
Daniel.

Re: [Unity-idm-discuss] custom claims in id/baerer token

[Roman K. <ro...@un...>]

Hi Sander,

This is currently not supported, but it sounds like a legitimate feature.
I'll open a ticket to cover this, and put it on top of our OSS queue of
requests.
Please note that we have recently changed the prioritization of tickets and
such requests are now evaluated and handled on a release basis. It is very
likely we will be implementing this sooner than later given the latest
process changes.

Best,
Roman

wt., 11 sty 2022 o 11:51 Sander Apweiler <sa....@fz...>
napisał(a):

> Hi Krzysztof,
> we have the request from a user to put some attributes in the id token
> to avoid querying the userinfo endpoint. Is this possible to add some
> claims to the default ones in unity? I had a look in manual section
> 14.14 but didn't find something.
>
> 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. Astrid Lambrecht,
> Prof. Dr. Frauke Melchior
> -----------------------------------------------------------------------
> -----------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> Unity-idm-discuss mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss
>

[Unity-idm-discuss] custom claims in id/baerer token

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

Hi Krzysztof,
we have the request from a user to put some attributes in the id token
to avoid querying the userinfo endpoint. Is this possible to add some
claims to the default ones in unity? I had a look in manual section
14.14 but didn't find something.

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. Astrid Lambrecht,
Prof. Dr. Frauke Melchior
-----------------------------------------------------------------------
-----------------------------------------------------------------------

[Unity-idm-discuss] Unity 3.7.2 with another log4j patch

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

Dear Subscribers,

Unity 3.7.2 bundling an updated log4j library (2.16.0) with a fix for 
the CVE-2021-45046 
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046> 
vulnerability was published today.

If you can’t update immediately follow the instructions from the 
previous post on the topic.

Links and changelog available in Downloads 
<https://www.unity-idm.eu/downloads/>.

Best regards,
Krzysztof

[Unity-idm-discuss] Update on log4j vulnerability

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

Hi Tim, All,

W dniu 15.12.2021 o 08:37, Tim Kreuzer pisze:
> Hi Krzysztof,
>
> I don't know if you already know, but another log4j update
> is required:
>
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

Yes, we are heads down on this one since morning.

Unity 3.7.2 including updated library is being released. It takes ages 
as sonatype nexus server (tool used to publish to Maven central repo) is 
super slow (quite easy to guess why). After this is completed I will 
provide a separate update.


Investigation of the new vulnerability discovered that there Unity 
server can be affected assuming:

1. it is version 3.5.0 or newer. 3.4.5 and earlier versions are not 
affected. Note: the previous log4j vulnerability was affecting all Unity 
versions (maybe except some ancient ones - we haven't checked unity 1.x 
or 2.x).

2. Context variables are used in logging configuration. Context 
variables is used when you use any of the following variables in logging 
pattern: ${ctx:___},  %X,  %mdc,  %MDC.


To mitigate the problem, until 3.7.2 is installed, the following options 
are available:

1. Manual update of all log4j* libraries to version 2.16.0. Should be 
safe on all affected versions of Unity.

2. Make sure you don't use any of the context variables in logging 
pattern layout. More precisely there is a single context variable in 
Unity which looks likely as a candidate for attack, but the safest bet 
is to not use context variables at all, until the patched version is 
installed.


Best regards,
Krzysztof

[Unity-idm-discuss] Unity 3.7.1 with log4j patch

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

Dear Subscribers,

Unity 3.7.1 bundling an updated log4j library with a fix for the 
CVE-2021-44228 
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228> 
vulnerability was published today.

If you can’t update immediately follow the instructions from the 
previous post Log4j vulnerability 
<https://www.unity-idm.eu/2021/12/13/log4j-vulnerability/>.

Links and changelog available in Downloads 
<https://www.unity-idm.eu/downloads/>.

Best regards,
Krzysztof

[Unity-idm-discuss] Log4j vulnerability

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

Dear Subscribers,

As you may noticed Unity is using the vulnerable log4j library (see CVE 
<https://nvd.nist.gov/vuln/detail/CVE-2021-44228> for details). Version 
3.7.1 (soon to be published) will contain a fixed dependency. Until it 
is available (and in cases you can't upgrade stright away) the following 
workaround is strongly advised.

In the file |conf/startup.properties| add the following line towards the 
end of the file:

|OPTS=$OPTS" -Dlog4j2.formatMsgNoLookups=true"|

Server restart is required after this change.

Best regards,
Krzysztof

Re: [Unity-idm-discuss] Unity Keycloak RP

[Bernd S. <b.s...@fz...>]

hi Anthony,

we have the UNICORE authentication by Keycloak OAuth tokens up and
running (the EBRAINS IdP is Keycloak).

To complememt what Krzysztof has written, you'll need an input
translation profile that maps the info from the token to an x500 identity

I've attached two screenshots, the one is the authenticator config, the
other the input profile. Of course the authenticator needs to be active
on the UNICORE SAML SOAP endpoint

Hope this helps!

Best regards,
Bernd



On 03.12.21 22:27, Anthony M wrote:
> Hello,
>
> Currently, I have incorporated Unity as an OAuth client using Keycloak. This allows users to login to the /home endpoint, resulting in user creation (including X500 name). However, I want to authenticate these newly created users through UNICORE by passing OAuth tokens (from Keycloak). I set up a Oauth RP in Unity by including the Keycloak “openid-connect/token/introspect” endpoint for token verification, and respective Keycloak profile endpoint (/userinfo). In addition, I connected the RP to a SAML SOAP endpoint (unicore-soapidp-oidc/saml2unicoreidp-soap/AuthenticationService). However, user authentication is failing.
>
> What would be the necessary steps to get this workflow working? Currently I have no remote data mapping set up with the OAuth RP, which may be causing issues when trying to map the verified tokens to the SOAP endpoint.
>
>
> Thank you for your help.
>
>
>
> Regards,
>
> Anthony Mammoliti
>


--
Dr. Bernd Schuller
Federated Systems and Data, Juelich Supercomputing Centre
https://www.fz-juelich.de/ias/jsc/EN/Home/home_node.html
Phone: +49 246161-8736 (fax -8556)


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
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. Astrid Lambrecht,
Prof. Dr. Frauke Melchior
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------