This message was deleted.

Hello, I have been using OPA for a little while and am rewriting some XACML policies. I have just recently begun starting to move to OPAL to get the data I need for decisions and enable real-time updates to the policies. So far everything is working great! I have a question though regarding policy sources. It seems that the OPAL server will only track one policy repository. I have a use case where I have some policies and "helpers" for filtering that will benefit the entire organization, but I want applications to be able to write their own policies as well without sharing a single repository. I'm envisioning a repository to hold the organization-wide policies and functions, then individual applications or groupings of applications can have their own repositories for their policies. When they configure an OPAL server, it could track both the organization repo and the lower domain repo. Is this a use case OPAL can handle? Or something that could be added in the future? Or if you think it's a useful feature maybe someone could point me in the direction of where I could look in the code in order to implement the feature and submit a PR. Thanks!

Hi @David Hamilton 🙂 👋 I think what you’re looking for is OPAL scopes : https://docs.opal.ac/overview/scopes

Aha! Thank you! Can scopes be inherited? Or can an OPAL Client be launched with a list of scopes?

Sorry was on a call. Scopes is a new feature. For now it’s one scope per client. You can of course have multiple clients.

Sure thing, and thanks for your quick help! Basically what I'd like to do is have a repository that houses policies that should be applied pretty much across the board. This also includes the "helpers" I was talking about. Then at a lower level, I want domains or applications to be able to add their policies to that, but in a repository they can control. So as a simple example, when we are dealing with data about a person, we have a concept of sensitivity of a person's record. Each person has a sensitivity level which is a number, the higher, the more sensitive the record is. Each user has an access level to indicate what level of sensitivity they can access. Now, it doesn't matter really what the user wants to know about a person, if they have a sensitivity level higher than the user's access level, the user cannot get any data about them. This is an example of something that is applied at the organization level repository. Now let's say I have a domain "documents" and I am creating RBAC/ABAC rules about accessing documents. I want the document domain to have its own policy repository, but be able to easily apply rules about sensitivity. So if a user tries to access a document for a person that is a higher level of sensitivity, then they would be denied. I want this to be as simple to configure from the domain level as possible. Basically they should be able to indicate that the document applies to a person id, and the person sensitivity policy would apply

Hi David, Scopes currently can't extend one another, but we are working on more flexible policy sources which will allow pulling policy from multiple repositories. For now, you can work around this limitation by keeping each scope in a separate repository that has the same upsteam (i.e. each project repo is a fork of the main one), so your shared policies can be in your main repo, and you merge changes into the different project repos. This is actually exactly what we currently do for our internal autogenerated repos in Permit.io.

Ok awesome! I will start with that path. I am still mostly on the proof-of-concept level but I am trying to plan for the future. When I get past the initial configurations and have started getting policy and data applied, I'd be happy to help out with enhancing the scope functionality

Great!