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