Adding roles #1632
Comments
|
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 if you're having loads of teams.
There is stevespringett/Alpine#674 which aims to make it possible to assign permissions to individual API keys. But I doubt your proposed changes will have any overlap there, so you should be good.
Awesome! Let us know if you need anything! |
|
@nscuro For additional context, I wanted to lay out the ultimate goal we are trying to accomplish. I can create a separate issue if that would be more appropriate.
We are kicking around the idea of creating a GitLab integration within Hyades. Here is what we have so far (link), just don't pay too much attention to the current code within One issue we're running into is that the privacy of /cc @pkwiatkowski1 @ashearin @Strakeln @lmphil @jmayer-lm @EphraimEM |
Depending on what exactly you need from Alpine has something similar for customization of the
The main chunk of work is coming up with a good interface contract that perhaps allows for more than just GitLab to integrated in a similar fashion. Do you think this could work for your case?
An asynchronous task (or workflow in the future) should be able to achieve this. However, IIUC, you need the users' GitLab access token when performing the synchronization?
For completeness, we also have a bare-bones plugin mechanism you could look into. Example for pluggable file storage:
The intention is to eventually publish the plugin API to Maven Central, and load plugin JARs from the file system. But this could be expedited if you find it useful in this context. I figure this would be a viable option if your desired solution ends up being too specific to LM. |
|
@nscuro Great info, thank you! We're exploring the customizer/claims extractor route now |
@nscuro Do you have any recommendations for what the type parameter to @FunctionalInterface
public interface OidcAuthenticationServiceCustomizer extends Consumer<ClaimsSet> {
}or maybe just the @FunctionalInterface
public interface OidcAuthenticationServiceCustomizer extends Consumer<AuthenticationService> {
}Thanks for all the help and suggestions! |
|
@jhoward-lm That really depends on what specifically you want to achieve. You are not limited to interface OidcAuthenticationCustomizer {
// Could be necessary if you have special needs for mapping claims
// to an OidcProfile (i.e. to extract team membership).
//
// https://github.com/stevespringett/Alpine/blob/38cdda1eea6e1bed45ae7e26e305338cd5ca75be/alpine-server/src/main/java/alpine/server/auth/OidcAuthenticationService.java#L129-L136
OidcProfile createProfile(ClaimsSet claimsSet);
// This decision currently drives whether only the ID token,
// or additionally the /userinfo endpoint is used to authenticate.
//
// The default implementation short-circuits if the profile is
// considered complete based on the ID token alone.
// https://github.com/stevespringett/Alpine/blob/master/alpine-server/src/main/java/alpine/server/auth/OidcAuthenticationService.java#L210-L214
//
// If you need to ALWAYS call the /userinfo endpoint,
// you obviously need to modify the decision logic.
bool isProfileComplete(OidcProfile profile, boolean teamSyncEnabled);
// If the service used both the ID token and the /userinfo endpoint
// to gather profile information, you need to decide what data to keep.
//
// https://github.com/stevespringett/Alpine/blob/38cdda1eea6e1bed45ae7e26e305338cd5ca75be/alpine-server/src/main/java/alpine/server/auth/OidcAuthenticationService.java#L216-L223
OidcProfile mergeProfiles(OidcProfile left, OidcProfile right);
// Invoked by OidcAuthenticationService when the authentication succeeded.
// Here is where your main logic could be. Since the user is authenticated
// at this point, it's safe to kick off a reconciliation job for them in the background.
//
// You could pass in the ID and access token as well.
void onAuthenticationSuccess(OidcProfile profile);
// Just for demonstration, might not be needed.
void onAuthenticationFailure(OidcProfile profile, Exception cause);
// For conflict resolution, see below.
int priority();
}You could replace To discover and load such a customizer, you could do it as follows. Note that there can be multiple implementations, and you'll have to choose only one. Again, this is just a rough sketch of how you could do it: // in OidcAuthenticationService#authenticate
var customizer = ServiceLoader.load(OidcAuthenticationCustomizer.class).stream()
.map(ServiceLoader.Provider::get)
.filter(customizer -> {
// Here's where you could further narrow down which implementation to use.
// i.e. if the authentication is performed with a GitLab IdP, only choose
// customizers meant to be used with GitLab.
})
// If you have multiple implementations still, order them by priority,
// and select the first of them. For example, a default implementation provided
// by Alpine should have a lower prio than a specialized one provided by DT.
.sorted(Comparator.comparingInt(OidcAuthenticationCustomizer::priority))
.findFirst()
.orElseThrow(IllegalStateException::new);
// ...
if (customizer.isProfileComplete(idTokenProfile, teamSyncEnabled)) {
// ...Alternatively, add a String customizerClassName = Config.getInstance().getProperty(Config.AlpineKey.FOO);
var customizer = ServiceLoader.load(OidcAuthenticationCustomizer.class).stream()
.filter(provider.type().getName().equals(customizerClassName))
.map(ServiceLoader.Provider::get)
.findFirst()
.orElseThrow(IllegalStateException::new);Users can then configure this via env vars, i.e. |
|
@nscuro This is way above and beyond the level of assistance we were hoping for, thank you so much! If going with Going to explore this avenue now, thanks again! |
|
@jhoward-lm Feel free to modify visibility or other internals as necessary. |
|
@nscuro When you get a chance, would you mind taking a look at the changes I have so far? This more or less covers what we've talked about, but I wanted to get it in front of you early in case I misunderstood anything or it looks like there are too many touch points in the code. I tried to keep the formatter in my editor from taking liberties but there might be some whitespace changes in there; let me know if I need to revert. A couple of highlights:
Thanks! |
|
@nscuro Or I could open a draft PR if you prefer |
|
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 Wouldn't it suffice to simply invoke Edit: Writing this made me realize that commenting on a PR would make this easier. If you could raise one for that purpose, that would be great. |
Current Behavior
Roles currently do not exist in Hyades/Dependency Track. The existing permission model composes of individual permissions aggregated at a global level in the jwt claim and teams as a mode for having a select set of permissions against a set of projects for a set of users.
Proposed Behavior
Hi friends,
We are looking into adding roles into the alpine framework and into Hyades as an expansion and enrichment of the permission system.
I don't think anyone else is working on this or the permission system so we shouldn't be clobbering anyone's work in progress, but let me know if that isn't the case.
We have a new team, and they are exploring how to best approach this without making major revisions to the existing permission model, so we will be updating this as we are moving along and creating PR's of the incremental work moving forward.
Checklist
The text was updated successfully, but these errors were encountered: