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

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

Hi,

W dniu 22.02.2022 o 07:57, Sander Apweiler pisze:
> 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.

OK, so I think everything is clear here. I'll open a ticket, we will 
prioritize it, I think that won't be big work, so should be sooner than 
later.

Best,
Krzysztof