Permission granting for role based access control

[SemanticBeeng]

@fspinnenhirn what is the java code that would produce this data?

https://github.com/acciente/oacc-example-securetodo/blob/6be7137f73ab648f3ab9c0430ccb662c01184ed2/src/main/resources/migrations_oaccdb-3-appDomain.xml#L24-L34

Trying to develop something following assignUserRole but the execution depends on the data in this initialization file.

Would you be kind to supply the Java code that would make this entire file not needed?

[adinath-raveendraraj]

@SemanticBeeng if you are asking about how to setup the database tables that OACC uses in general, it is done via SQL scripts for each of the databases we support -- creation of the database tables is not done using Java. You can find the DDL scripts for the supported databases in this GitHub repo: https://github.com/acciente/oacc-db

After you create the tables you do need to set their initial table data using a Java OACC initializer. You can find detailed instructions on how to create the tables and initialize them in the sections "2. Database Setup" and "3. OACC Initialization" of this tutorial: http://oaccframework.org/getting-started-tutorial.html

Please let me know if this answers your question.

[SemanticBeeng]

Thanks Adinath.

Looking for the " Java code that would make this entire file not needed" - please see above for the file in question.

Wondering what api calls to use to produce such records https://github.com/acciente/oacc-example-securetodo/blob/6be7137f73ab648f3ab9c0430ccb662c01184ed2/src/main/resources/migrations_oaccdb-3-appDomain.xml#L106-L132

[SemanticBeeng]

The specific issue is due to this failure trying from my attempt to mimic assignUserRoles

Resource {resourceId: 2, externalId: "(role) [(class) signing_key]-owner-helper"} is not authorized to grant the following permission(s): [*INHERIT]

I must be doing something wrong related to table OAC_GRANT_RESCRPERM_POSTCR. In my app am using Java apis to populate because manual setup as in the example above is not desired.

Does this give any ideas, please @adinath-raveendraraj ?

[adinath-raveendraraj]

@SemanticBeeng sorry for the delayed response -- the error message cited in your last question makes the issue very clear.

Say the currently authenticated user (resource-A) is trying to grant INHERIT to another user (resource-B) on a role (resource-C) -- for this to be allowed resource-A must have the INHERIT / G (with grant) permission on resource-C, otherwise the error you cited will be thrown. When you attempt grant *INHERIT on a resource the post-create permissions do not play a role, what is checked are "resource permissions". In our example, resource-A can have needed permissions on resource-C in any one of the following ways:

1) resource-A has the (direct) resource permission INHERIT /G on resource-C -- resource A would have received this at some point via a call to setResourcePermissions(...) 2) resource-A has the global resource permission INHERIT /G on the domain containing resource-C -- resource A would have received this at some point via a call to setGlobalResourcePermissions(...) 3) resource-A has the *SUPER-USER permission to the on the domain containing resource-C -- resource A would have received this at some point via a call to setDomainPermissions(...)

Does this make sense? Let me know if you have further questions.

P.S. Also setting up the initial permissions using the APIs (usually logged in as the initial root user) is the correct way to do it -- you should not be directly inserting rows into the OACC tables.

[SemanticBeeng]

This helps, thanks - trying to work with that.

"When you attempt grant *INHERIT on a resource the post-create permissions do not play a role,"

But then why the rows in OAC_GRANT_RESCRPERM_POSTCR ? This is the only place where 'todo-creator" and "todo-creator-helper" are mentioned in relation to assigning permissions (withGrant). In code, PERM_INHERIT is not withGrant.

Would you be kind to change this example to achieve same effect by using APIs to replace this table (appDomain.xml) ? It would be most effecting to understand and would benefit this example app anyway - this initialization is not explained in the documentation and it kind of "hits" you when running into the need for it.

Many thanks for support @adinath-raveendraraj !

[adinath-raveendraraj]

@SemanticBeeng the example app was written by @fspinnenhirn and I am not super-familiar with it -- I will need to check out the example and take a look when I get a chance (which may not be for a while) to answer any specific questions about that example. One reason it has those database DML scripts is because @fspinnenhirn was trying to make it easy to just download and run the example -- and DropWizard was used to help with that. What I see is that the example is granting post-create permissions using roles, which is just something specific to the example. There is a nice document explaining the security model used in that app here:

https://github.com/acciente/oacc-example-securetodo/blob/master/walkthrough/secure-todo-example.md

I do not plan to change this example, if time permits in the future, I may create a simple new example that only uses API calls -- it is not difficult to setup permissions using the API.

I am using OACC in a large project currently and I have RBAC style roles using OACC and no post-create permissions are used. Post-create permissions are the permissions that you would grant a user (resource) on a particular resource type when you want that user to have a certain permission when that user creates a new resource of that type. For example you could grant READ, WRITE, DELETE post-create permissions on the type DOCUMENT so that the user automatically gets READ, WRITE, DELETE on any document they create.