 |
Related Topics: |  |
 |
 |
|
 |
 |
 |
For every project in a secure database, there is a choice of which type of security will control how users can access the project. In general, we recommend to:
Use repository-level security if you want all projects to be accessible to any user account that is assigned to at least one security group.
Use project-level security if you want different users to have different levels of access for different projects
Tip: Although it is possible for some projects in the database to use repository-level security and other projects to use project-level security, it is generally recommended to configure all projects with one type or the other.
Both security methods use security groups to determine the permissions that users will have within projects. A security group is a set of permissions that can be granted to user accounts, with permissions ranging from read-only access to full administrative authority. Users with the “Manage users and logins” permission can use the Manage Repository Security window to set up security groups and users.
To set or change a project’s security, use the Security tab of the Project Properties window. You will need at least one of the following roles/permissions to access this tab:
You can configure the security settings of any project for which you are assigned as the project owner.
You can configure the security settings of any project for which you have the “Set project security" permission.
If you have the "Manage all projects" permission, you can also use the Manage Projects window to view and edit the properties of all projects in the database.
The following example shows the security groups that are created by default when you create a new database. The Admin group, which provides full permissions for all features and all analyses in the repository, cannot be deleted and the properties cannot be modified. For the other predefined groups, you can edit their permissions or replace them with new groups that fit the specific way that the repository will be used.
If all projects in the database use only repository-level security, then all users will have the specified level of access for all projects. For example, with the basic set of security groups that are created by default in a new database, user accounts assigned to the "View" security group will have read-only access to all projects in the database, whereas user accounts assigned to the "User" security group will have read and write permissions to all projects.
If you need the repository to provide users with different levels of access for different types of projects, then you will need to implement project-level security, as described in the next section.
Project-level security allows you to control which security group(s) or individual user(s) can view or edit each individual project.
For example, suppose you want to grant a user read/write access to all projects that belong to her own organizational group (Department A), read-only access to all projects that belong to another group (Department B and Department C), and no access at all to projects that have been classified as "Confidential." In this case, you would create a security group for each type of access, and then assign the appropriate security groups to the user's account. The settings for this scenario are shown next.
Next, you must limit access to each project in the repository based on specific security groups and/or users (i.e., select Use specific security groups and users on the Security tab of the Project Properties window). The following picture shows the security settings for one of the projects maintained by Department A. This configuration shows how access may be limited by security group(s).
In this example, users assigned to the "Department A" security group will be able to access the project with the full set of read/write permissions that have been granted to that group, while users from other departments who are also assigned to the "Read-Only" security group will have the limited read-only permissions that have been granted to that group.
Now assume that Department A is working with an outside consultant for one of their many different analysis projects. To configure the database to allow this consultant to have individual access to only one specific project, you assign her account to a new security group called “Consultants.” This new group defines the permissions that will be available to a consultant for any particular project that he/she might be individually assigned to. Then you use the Limit by Users option to give her these permissions for only one of the Department A projects, as shown next.
Note that if a particular user is assigned in the Limit by Users area and is also a member of one (or more) of the groups assigned in the Limit by Groups area, the user will have the least restrictive set of permissions. For example, suppose that Jane Consultant later becomes a member of the Department A group. Even if you clear the “Create project items” check box under her name in the Limit by Users area, Jane will still have the permission for this project because she belongs to the Department A group. Likewise, if the Department A group does not have the “Delete project items” permission, but Jane is eligible for that permission from another security group that is not assigned to the current project, then if you select the “Delete project items” check box under her name, Jane will have an additional permission in this project that is not available to the other members of the Department A group.
© 1992-2013. ReliaSoft Corporation. ALL RIGHTS RESERVED.