Establishing Security for the Repository
Go Up to Working with ERStudio Repository
Security of the Repository contents is managed by the Repository Administrator through the Security Center by creating and then assigning users particular Groups, Roles and Privileges.
To open the Security Center going to Repository > Security > Security Center.
Note: To prevent an accidental lockout, the Admin user cannot be deleted.
For example, we create a user JimB, give him a Role and call it DBA. The DBA role has many privileges, but none allow the DBA to modify a logical model. A Repository administrator can associate JimB with any model in the Repository and he will not be able to modify the diagram's logical model, but he can view it.
The Administrator can restrict user and group access to Repository items at the project, diagram, model, submodel, and data dictionary levels. To restrict access to the Repository, the Administrator creates users and then assigns the users a default role or assign, which grants specific permissions to the user, or creates new roles to assign to users. The Administrator can alternatively create a group of users and assign a role to that particular group. In these ways, the Administrator can grant users full access to some Repository items and restrict or deny access to others items.
Before creating users, groups,and roles, the Administrator should understand the following Repository concepts:
- Cascading Security: To make it easy for Administrators to assign a role globally to users when there are many diagrams in the Repository, such as when the user must have the same access permissions to many of diagrams, the Administrator can assign a user and role to various 'levels' of the ER/Studio Repository.
For example, a Project can be created in the ER/Studio Repository that contains many diagrams. If you assign a user a role to this Project, any diagrams contained within the Project will be granted the same permission set. The Repository itself can act as this highest-level point to assign permissions that are cascaded down.
Higher levels can be overwritten by assigning the same user different roles at a lower level, for example UserA may have the Viewer role at repository level but Modeler role for a specific diagram or submodel.
- Client Side Security Caching: To promote the concept of detached modeling collaboration (e.g. being logged out of ER/Studio Repository and possibly detached from the network), all security associated with the user by diagram is cached on the client when the user logs into ER/Studio Repository.
Note: When security changes are made, users must re-login to update their permissions.
- Super User: Super User is a default Role created upon installation of ER/Studio Repository. The default 'Admin' user is assigned to the Super User role. This user can do anything to diagrams, users and roles managed in the ER/Studio Repository as it is granted all privileges. It is not removable or editable, and is only found at the 'Repository' level of the Repository Security area of the Security Center.
- No Access: No Access is a role that can be applied only at the project and diagram levels of the Repository. It is a quick and global mechanism to prevent any access whatsoever to diagrams managed in specific projects, or to individual diagrams themselves. For example, you can create a group and assign it to the no access role for a project, then any users added to the group will not have access.
- Additive permissions: Permission granted to a user by group membership are additive. The user will have all the permission granted to him plus the permissions afforded him by group membership.
Notes
- When a user gets a file from the Repository, ER/Studio Data Architect tracks the user and machine combination for that particular file. In addition, to enable users to model while they are "offline" or unable to connect to the Repository server, ER/Studio Data Architect stores information about the security rights of the user and the diagram with the file, which has the following effects:
- When a user is logged into the Repository, and attempts to open a DM1 file that was retrieved from the Repository by a different user/machine combination than the currently logged in user, ER/Studio Data Architect indicates that the file cannot be opened due to the conflict. This ensures that one user does not attempt to work on or check in changes to a diagram that was originally retrieved by a different user. Because the Repository keeps track of object check outs based on the user and machine, only the user on the machine that originally checked out an object can check it back in.
- Even if a user is not logged into the Repository, Repository DM1 files can be opened and worked on in ER/Studio Data Architect. ER/Studio Data Architect will load the security permission data for the user that originally retrieved the file from the Repository, and that security data will govern the rest of the working session until the user either logs in to the Repository or closes the file. If multiple files are open while the user is NOT logged in to the Repository they must all have been retrieved by the same user. Of course, this also applies when the user IS logged in.
- The cached security data stored with each diagram is updated whenever an open Repository file is saved while logged in to the Repository, but if the file is not saved before closing it, then any changes to the security permissions for that user and diagram will not be cached with the file. So, if you plan to work offline, and the security settings have changed since the file was last saved, then you should open each file while logged into the Repository and save it before taking the files to work offline.
- Permission settings can be applied at the project or repository level, which might cause a conflict when two files are opened while a user is offline. If two files are opened that both have cached security information for the Repository level or for the same Project, and if the cached data differs, then the most recently saved data will be used and stored in both files if and when they are saved.
- If an admin makes changes to the security UI, such as changing permissions on folders to grant or revoke access or moving diagrams between projects with different permissions, users must re-login to update their permissions.
This section also includes the following:
- Creating and Managing Roles
- Creating and Managing Users
- Creating and Managing Groups
- Granting and Prohibiting User Access to Repository Items