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. |
|
@nscuro returning to the core task of adding roles as a way of enhancing access control to allow for project scoped permissions and avoiding globally aggregated permissions for a user. We've drawn up some preliminary diagrams to illustrate our proposed changes and would love some feedback on them.
edit: adjust layout of proposed tables to enhance readability |
|
@ashearin The model makes sense. Few questions:
|
Correct.
I'm sure Allen will have his own thoughts on it, but just my opinion here. My expectation for permissions behavior would probably be something like "closest scope wins", or "most explicit wins". i.e. in order of descending precedence:
Then permissions are merged into an effective access for a given project. I would need to see how the permission levels in DT are organized and inherited, i.e.
How is portfolio access control permission inheritance handled currently? My first inclination would be to align with that. Of course, this whole effort is in support of mapping GitLab project roles to Dependency Track projects and scoped permissions, and in their model, permissions at the group level are inherited for all projects, and the highest access level of the permissions tree for the project wins. For example, if a user is assigned |
At the moment, This check for
Historically it did not take hierarchy into consideration, because it was too expensive to compute for many projects at once, e.g. when listing all projects. A technical limitation and a known feature gap. I am currently in the process of changing that: |
|
@nscuro I opened a Draft PR with our initial pass at implementing the diagrams we linked. Currently only adds the role and mapped role classes with needed relational tables and a migration file update. We're still working on associated changes needed to enforce permissions scoped to the Project level, but wanted to get some feedback as we progress. |
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: