Niklas

Hey @mfrystacky, I think adding the concept of roles makes sense. I think teams were somewhat meant to implement RBAC-like capabilities, but of course this model doesn't scale that well...

> Get the user's group memberships within GitLab and corresponding effective access levels (roles such as owner, maintainer, developer) for each of these groups using the GitLab API > *...

@jhoward-lm That really depends on what specifically you want to achieve. You are not limited to `Consumer` either. To give you a very rough idea: ```java interface OidcAuthenticationCustomizer { //...

@jhoward-lm Feel free to modify visibility or other internals as necessary.

I did not have the chance to look at it yet, I'll try to give you feedback later today.

@jhoward-lm This looks quite promising already. But do you need to customize large chunks of the authentication logic itself? Otherwise I'd suggest to not move `authenticateInternal` to the customizer. Same...

@ashearin The model makes sense. Few questions: * Do I understand it correctly that this is *in addition to* the existing `PROJECT_ACCESS_TEAMS` model, and this is solely for a more...

> I would need to see how the permission levels in DT are organized and inherited, i.e. ACCESS_MANAGEMENT automatically implies VIEW_PORTFOLIO, etc. At the moment, `ACCESS_MANAGEMENT` bypasses ACL checks. Logic...

I think the biggest problem ATM that needs solving is: *How do we make access checks perform well?* What's problematic about the model proposed in https://github.com/DependencyTrack/hyades/issues/1632#issuecomment-2663960532, is that it must...

> Would careful/thoughtful design leveraging indexes mitigate this somewhat? I mean yes, but thoughtful design is also somewhat of a wildcard 😅. IMO the benchmark for this should be listing...