Establishing Security for the Repository
Go Up to Working with ER/Studio Repository
Security of the Repository contents is managed through the Repository Security Center by creating and then assigning users particular Roles and Privileges.
- Note: To prevent an accidental lockout, the Admin user can’t be deleted.
The Administrator can restrict user access to Repository items at the workspace level. To restrict access to the Repository, the administrator creates users and then assigns the users a role, which grants specific permissions to the user, or the administrator creates new roles to assign to users. Then the Administrator can grant users full access to some Repository items and restrict or deny access to other items.
Before creating users and roles, the Administrator should understand the following Repository concepts:
- 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 Repository objects, 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 workspace level of the Repository. It is a quick and global mechanism to prevent any access whatsoever to certain workspaces.
Notes
- When a user checks out a workspace from the Repository, ER/Studio BA 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, when a workspace is checked out, ER/Studio stores information about the security rights of the user and the workspace with the file, which has the following effects:
- When a user is logged into the Repository, and attempts to open a workspace that was retrieved from the Repository by a different user/machine combination than the currently logged in user, ER/Studio BA 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 workspace 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 files that have been checked out can be opened and worked on in ER/Studio BA. ER/Studio BA 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 workspace 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.
- If an admin makes changes to the security UI, such as changing permissions on worspaces to grant or revoke access, users must re-login to update their permissions.
This section includes the following topics:
- Creating and Managing Roles
- Creating and Managing Users
- Granting and Prohibiting User Access to Repository Items
See Also