🚀 RBAC: Evaluation without users in catalog

[bcorijn]

Plugin Name

rbac-backend

🔖 Feature description

I am using a proxy auth provider (oauth2-proxy to be specific), where I don't have my users loaded into the catalog and use a custom signInResolver. However, I can validate their identity and their ownerships resolution of any groups deemed relevant through my OIDC client's response and custom signInResolver code. I had hoped I would be able to use RBAC and specify policies that used these ownership references and evaluated them "at-runtime". However, it looks like RBAC does not really take into account any ownership reference that my user object has.

🎤 Context

It is not feasible for me in my organization to populate the org-data in the catalog, however I can build the ownerships at sign-in (as suggested in the docs). This does not seem compatible with the RBAC plugin?

✌️ Possible Implementation

From what I understand, currently the plugin always builds a graph from the catalog and relies on that. Would it be doable to look at the current user's ownership references and base decisions off of that too? Is there any way I can do with conditional policies or does the plugin always rely on the catalog-based graph?

👀 Have you spent some time to check if this feature request has been raised before?

• [X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• [X] I have read the Code of Conduct

Are you willing to submit PR?

No, I don't have time to work on this right now

[PatAKnight]

Hello! and thank you for opening up a feature request for the RBAC backend plugin

This is interesting, I never thought of a scenario where it wouldn't be feasible to populate the catalog with org information.

I need to double check but it does look doable. In handle, whenever we are evaluating for a permission policy, a PolicyQueryUser is passed. This PolicyQueryUser has information on the user and ownership refs through BackstageUserIdentity.

export type PolicyQueryUser = {
    token: string;
    expiresInSeconds?: number;
    identity: BackstageUserIdentity;
    credentials: BackstageCredentials;
    info: BackstageUserInfo;
};

export type BackstageUserIdentity = {
    type: 'user';
    userEntityRef: string;
    ownershipEntityRefs: string[];
};

At this time, I will pass this feature request on over to our PM for review.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[awanlin]

Any updates?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[PatAKnight]

Just an update, in case the stale bot does end up closing this at some point, we are also tracking this issue on our side here and are working to prioritize this against other requirements that we currently have. Thank you for your patience.

[JohannesWill]

I'm doing a POC for sign-in fallback for users not in the catalog introduces in Backstage v 1.39.0 and I'm encountering the same issue.

[JohannesWill]

I tried to address the issue by introducing an optional defaultRole, which is assigned to all users. However, since I’m not very familiar with the RBAC plugin, I can’t make a detailed statement about the security implications of this approach.

https://github.com/JohannesWill/community-plugins/tree/poc/default-role

@PatAKnight do you think this would be a viable approach?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[JohannesWill]

PR still in review

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[christoph-jerolimov]

Adding do not stale label since this is an important feature request and afaik this will be addressed in the near future.

@BethGriggs @schultzp2020 @PatAKnight maybe it's worth having a roadmap section in the rbac readme or a ROADMAP.md in the workspace? Or at least you can share something about the timeline for this (if there is a timeline for this)

[dzemanov]

We are tracking the prioritization for this feature in this Jira ticket: https://issues.redhat.com/browse/RHIDP-5131. The work for adding optional default roles and permissions is tracked in https://issues.redhat.com/browse/RHDHPLAN-366.