Hi all,
I'm looking for some best practices regarding User Management and Access Control, but first, allow me to share some of our current landscape.
We have one database for the entire enterprise and we're having one of our users but heads with the ARIS admins over Access Control. Since we have one database which is the work area for many users, we've decided that the ARIS team will handle user access via user groups.This specific user wants the ability to manage individual user access at the folder level.
Question: Would enabling 'User Administrator' as a function privilege for this user open up the entire userbase to this user? This seems like too much power for one non-admin user to have.
Other questions: How do others structure their access control policies where each project area has differing requirements for managing users?
Thanks,
Tony
Hello Tony,
there are different function privileges. There is "User administration", which you assign in UMC. This gives the user the privilege to create and delete users, assign licenses to them, assign them to user groups and the like. I understand, this is not what you want for this user.
There is the function privilege "User management", which you define via the ARIS Architect client for each individual database (in your case only one). With this the user cannot create or delete users or change their group memberships. Instead he is entitled to give users or user groups privileges on the "folders" or "groups" as they are called technically in ARIS. I guess this is what you want. So when you log-in to the database, go to Administration tab and select "Users" or "User groups" below the database node. You can edit the privileges of users or user groups at database level and assign "User management" privilege.
So in a sense this privilege opens the entire database to this "user manager", because he could grant himself any privilege on any group. Obviously he should not do that. I understand he is member of the "ARIS team"?
Generally it is good practice to give everybody read access anywhere (unless you really have areas to be protected on a need-to-know policy) and write access only to the respective owners of artifacts in the different branches of your repository. You may even decide not to give delete privileges to owners to prevent them from deleting objects being used elsewhere, crippling other models and losing information. Instead they could flag objects to be deleted with some attribute, delete it from their library model, and when the last occurrence has been replaced in other places you have the regular "Reorganization" of the database get rid of the debris.
The user management privilege is database-wide. So it may be good practice in a large organization to process requests for changes to access privileges via a ticketing mechanism already established in the organization. This gives the opportunity to involve stakeholders before the "user manager" actually performs a change. Of course, this also applies to the "user administrator" who can make changes to group memberships.
Regards, M. Zschuckelt