On Aug 19, 2014, at 7:52 AM, 706826 <zahid.ahmed(a)emirates.com> wrote:
I want to put access control on the BRMS repository/project access,
developer-A can only work on repository-A. We have a central BRMS which has
one repository per project. We have 20 projects and have 20 repository, one
for each project.
Sounds good! Just one tip: project access control won't be supported anymore,
so the control should be on repository level.
We strongly want that user working on project-A must have access only on
project-A in BRMS.
So the use of 1:1 relation between project and repo is really the way to go.
I read the documentation that says,
*"The user either has to belong into a role that has access to the
repository or to a role that belongs into an orgazinational group that has
access to the repository. These restrictions can be managed with the command
line config tool."*
Our implementation to the above doc statement is to create custom roles for
each of our project. Then assign developer , analyst and admin permissions
to the roles and then assign these project specific roles only to the
project users. This way each project will have its own roles. And users
under those roles will be able to access only that project and repository in
Why not use Organization Units (OU) for such restrictions? IIRC, respository restrictions
are based on OUs not on role.
To do this we simply ran KIE-CONFIG-CLI commands like "add-role-repo" and
considered that roles got added to the BRMS. BUT WE ARE UNABLE to associate
the permission (read/write, developer/admin) to our custom roles.
and upon login we are getting error "Login Failed : UNAuthorized"
*QUESTION * How can we have the ACL implemented in BRMS. Is there something
which we are missing.
I think you should consider use OUs for such need - much like GitHub does.
View this message in context:
Sent from the Drools: User forum mailing list archive at Nabble.com
rules-users mailing list