Allow to use claims in access token or id token for openid user/group mappings

Current Behavior:

From what I understand, dependency-track uses the standard userinfo endpoint to fetch the user’s name and groups. This is limiting when using certain providers, for example Microsoft Identity.

Proposed Behavior:

Allow to use claims returned either in the access token or id token since these are also openid standards.
For example:

ALPINE_OIDC_USERNAME_CLAIM_SOURCE=userinfo/access_token/id_token
ALPINE_OIDC_TEAMS_CLAIM_SOURCE=userinfo/access_token/id_token

This would also solved the issue #979 . Thanks!

[nscuro]

We can’t reliably use the access token since it’s not guaranteed to be a JWT, or even parseable at all. Considering ID token and /userinfo when looking for claims sounds OK though.

If we submit both ID token and access token to the API server, we can always validate and decode the ID token first. If it’s valid, and we find all the claims we’re looking for in there, we don’t have to bother requesting /userinfo. A valid ID token is already enough as proof of authentication. If we’re missing claims, we can then request /userinfo with the access token. Meaning we don’t need the proposed properties that instruct DT where to look for claims.

I think I’ll give this a go. Will probably introduce the Nimbus OIDC SDK as we’ll now have to deal with retrieving and selecting the correct signing key from the IdP.

[yohanb]

@nscuro well I found my error…! typo in ALPINE_OIDC_TEAMS_SYNCHRONIZATION no ‘S’ on TEAMS Tested and it’s now working! 🎉