fspinnenhirn
commented
8 years ago Thanks for your question, Manos. For future reference, you also have the option of posting questions in the discussion forum of the OACC google group, if you wish.
Please see my responses below:
My understanding is that "user" resources can then be given the INHERIT built-in permission on the "role" to inherit permissions assigned to it.
That's correct, "roles" can be modeled as resources and have permissions assigned. To become a "member" of that role and acquire its permissions, a resource (one that represents a user, for example) needs the *INHERIT permission on the role-resource.
is it possible to similarly apply some concept of inheritance to resources used as permission targets under the same scope without actually creating copies of the original permissions? Are resource classes or domains relevant here?
Please help me understand your question:
You're not asking about redefining the permissions available on a resource, are you? In OACC available permissions are defined once per resource class and then available for any resource of that class.
When you say "without actually creating copies of the original permissions", are you trying to find a way that avoids having to assign a permission for each target resource that a "role" has access to? If that is the case, then yes, resource classes and domains are the key features that can help you with that, and to keep in mind when modeling your application objects as OACC resources. OACC has the concept of global permissions, where the "target" of a permission is not an individual accessed resource but is actually specified as a tuple of a resource class and a domain. These global permissions cover all the resources of that class within that domain, including any future resources that might get created. Domains can be hierarchical, so a global permission on a higher level domain would extend to resources within its nested child domains.
If, on the other hand, you're simply asking whether resources that are the "target" of a role's permissions (i.e. the accessed resources) can themselves inherit permissions from other resources, then yes - OACC supports multiple and hierarchical inheritance between any kind of resources.
would it be possible to implement custom business logic that allows resources to inherit different permission targets as described above during their lifecycle (i.e. based on some status or whatnot)?
OACC is fully dynamic - your business logic can assign and query permissions at runtime, including defining, assigning or switching roles of users. Without knowing more about your specific scenario, it's hard to provide you with concrete options or best practice guidelines.
I hope this helped answer some of your questions. Manos, please let me know if you want me to clarify anything or if you have further questions!
manosbatsis
This is more of a question than an issue.
Consider an app where a user dynamically (i.e. at runtime) defines a "role" as a oacc resource with permissions for a specific target resource. The scope of such a role would be limited in something like a user-defined workflow. My understanding is that "user" resources can then be given the INHERIT built-in permission on the "role" to inherit permissions assigned to it. Assuming that is correct:
a) is it possible to similarly apply some concept of inheritance to resources used as permission targets under the same scope without actually creating copies of the original permissions? Are resource classes or domains relevant here? b) would it be possible to implement custom business logic that allows resources to inherit different permission targets as described above during their lifecycle (i.e. based on some status or whatnot)?