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

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

Good morning,

On Mon, 2022-02-21 at 17:21 +0100, Marcus Hardt wrote:
> 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.

I agree too. The most clients might not be need this and those services
where we get the requests do not have their own clients and want to
reuse tokens which was created by someone else.
>  
> > 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).
> 
Yes make sens. Although most users use the remember function.

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