Re: [Wimse] JWT-based workload authentication via OIDC (ab)use

[Brian Campbell <[e-mail]>]

On Wed, Nov 29, 2023 at 8:21 AM Hannes Tschofenig <[e-mail]>
wrote:

> Hi all,
>
>
> after we posted [1] we got feedback that the description of how the
> workload proceeds interacting with the resource server may be
> over-specified and too specific and should instead be generalized.
>
>
> Reading the review feedback from Evan gives me the impression that there
> is probably a possible separation between
>
> (a) the interaction needed to present the workload with a token and the
> way to convert that token into something that can be used subsequently
> through the use of token exchange,
>
> and
>
> (b) the intaction that follows afterwards by the workload.
>
>
> I sounds a bit like (b) should be aligned with the work in the industry
> today, for example with [2]. Regarding Brian's draft
> <draft-schwenkschuster-oauth-identity-chaining>, I couldn't recognize a
> good alignment with [2]. [2] talks about re-using OpenID Connect while
> Brian's document doesn't.
>

Calling that stuff OpenID Connect is an understandable but (in this context
anyway) unfortunate misuse of the name. Beyond the terminology I believe
there is a lot of similarity. At least in the general concepts and flow.

"Workload receives platform token" is similar to a local token exchange
<https://www.ietf.org/archive/id/draft-oauth-identity-chaining-00.html#name-token-exchange>
to acquire a JWT suitable for cross-domain use where "Workload calls target
token exchange service, provides platform token" to acquire an access token
like "Target returns credential valid in target domain" which is similar to
the JWT Authorization Grant of RFC7523 and described/profiled/something in
the identity-chaining draft
<https://www.ietf.org/archive/id/draft-schwenkschuster-oauth-identity-chaining-00.html#name-authorization-grant>.




Ciao
>
> Hannes
>
>
> PS: Should <draft-schwenkschuster-oauth-identity-chaining> actually be an
> item to be worked on in WIMSE rather than in OAuth?
>
>
> Am 29.11.2023 um 14:52 schrieb Brian Campbell:
>
> On the face of it this sounds a lot like the JWT authorization grant from
> https://datatracker.ietf.org/doc/html/rfc7523
>
> This draft
> https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/,
> which was recently adopted by the OAuth WG
> <https://mailarchive.ietf.org/arch/msg/oauth/l6dGZNuyH7GyiNX9uz1C9R_SCRc/>
> attempts to further profile/describe the JWT authorization grant including
> mention of the metadata/JWKS and a local token exchange to receive the
> initial token.
>
> On Tue, Nov 28, 2023 at 3:48 PM Evan Gilman <[e-mail]> wrote:
>
>> Hannes' BCP draft on kubernetes workload identity tokens [1] discusses a
>> very common use case where a workload uses a platform-provided JWT to
>> authenticate to another service in a different identity domain. In the case
>> of the BCP, authentication to an OAuth Resource Server is discussed, which
>> uses the platform-provided token to "enter an OAuth domain" and receive an
>> access token. There are similar (perhaps even more popular) patterns e.g.
>> use a platform-provided token to "enter the AWS domain" by exchanging it
>> for a time-limited AWS secret access key. In fact, the latter pattern
>> exists in all three major cloud providers, and has been colloquially coined
>> as "Workload Identity Federation".
>>
>> Aside from the fact that "Workload Identity Federation" is a very
>> confusing way to describe this pattern, it has emerged as a powerful
>> primitive for cross-domain authentication and access. For example, there
>> are dozens of pages of documentation on how to do this against a variety of
>> targets on the GitHub website [2] ... in fact, it is the recommended way to
>> authenticate GitHub Actions CI runners to pieces of infrastructure.
>>
>> And yet, there is no standard way to do this.
>>
>> It works purely due to lax OIDC validators ... my read of the situation
>> is that this flow is an abuse of OIDC and nowhere is this pattern described
>> by text. The following gives a rough idea:
>> * Workload receives platform token
>>   * Often via disk (see [1])
>>   * Platform token has a variety of bits set, depending on platform
>>   * Token mocks an ID token, with a subject/issuer/audience, but lacking
>> most other things
>> * Workload calls target token exchange service, provides platform token
>>   * Target service is branded as OIDC-based authentication
>>   * Target service is configured with mappings, usually referencing sub
>> claim and sometimes others
>>   * Target service is configured with issuers
>> * Target pulls well-known OIDC discovery doc from issuer URL
>>   * Target follows JWKS link, everything else is ignored
>>   * (sometimes, target will be directly configured with JWKS URL and skip
>> the discovery doc)
>> * Target validates presented platform token against issuer using JWKS
>>   * Target refers to mapping to know what credential to return
>> * Target returns credential valid in target domain
>> * Workload proceeds on with its day
>>
>> It would be really great to capture this flow/pattern in a more formal
>> way. I think WIMSE could be a good place to do that. Even just giving it a
>> name would be valuable.
>>
>> [1]:
>> https://datatracker.ietf.org/doc/draft-hofmann-wimse-workload-identity-bcp/
>> [2]:
>> https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
>> --
>> Wimse mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/wimse
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._