Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add OidcAuthenticationCustomizer service provider interface #755

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

jhoward-lm
Copy link

This PR adds the capability to customize OIDC authentication with extended functionality if desired.

@jhoward-lm jhoward-lm force-pushed the oidc-auth-svc-customizer branch from 0c89533 to 15f49cb Compare January 30, 2025 17:38
@jhoward-lm
Copy link
Author

@nscuro Suggestions from DependencyTrack/hyades#1632 were implemented. Let me know if that looks a little closer to what you would expect, and if the onAuthenticationSuccess calls look correct. Thanks!

Copy link
Collaborator

@nscuro nscuro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a minor remark, otherwise looks good.

I guess the most important question is, does it help you in achieving what you want?

Comment on lines 189 to 190
customizer.onAuthenticationSuccess(profile, idToken, accessToken);
return qm.updateOidcUser(user);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be safe, since updateOidcUser could still fail:

Suggested change
customizer.onAuthenticationSuccess(profile, idToken, accessToken);
return qm.updateOidcUser(user);
user = qm.updateOidcUser(user);
customizer.onAuthenticationSuccess(profile, idToken, accessToken);
return user;

Same for other invocations. You want to make sure onAuthenticationSuccess is only called when you can be sure that the authentication succeeded.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think onAuthenticationSuccess might benefit from accepting and/or returning an OidcUser? So this would become something like

return customizer.onAuthenticationSuccess(qm.updateOidcUser(user), profile, idToken, accessToken);

That way, implementers would have access to user.setTeams(), user.setPermissions(), etc. inside onAuthenticateSuccess, if you think that would be useful and if it seems like an acceptable design pattern

@jhoward-lm
Copy link
Author

Just a minor remark, otherwise looks good.

Ok thanks, I'll implement that suggestion for all calls to onAuthenticateSuccess.

I guess the most important question is, does it help you in achieving what you want?

What I think is needed:

  • Access token for GitLab API requests
  • The following claims:
    • groups claim from /userinfo
    • groups_direct claim from /token
    • https://gitlab.org/claims/groups/owner claim from /userinfo
    • https://gitlab.org/claims/groups/maintainer claim from /userinfo
    • https://gitlab.org/claims/groups/developer claim from /userinfo
  • Create DT teams such as <GitLab project name>-maintainer
  • Assign a certain set of DT permissions (TBD) based on GitLab role
  • Might need to configure portfolio access control, not sure yet

Do you think this is currently achievable with these changes? Should the OidcUser be passed in to onAuthenticateSuccess in addition to, or instead of, the merged profile?

@jhoward-lm jhoward-lm force-pushed the oidc-auth-svc-customizer branch from adf94a7 to 398223f Compare January 31, 2025 17:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants