Managing Security Groups, Roles, and Permissions

18 Managing Security Groups, Roles, and Permissions

This chapter provides information on the use and management of security groups, roles, and permissions on Oracle WebCenter Content Server.

This chapter includes the following topics:

18.1 Introduction to Content Server Security Groups

A security group is a set of files grouped under a unique name. Every file in the Content Server repository belongs to a security group. Access to security groups is controlled by the permissions, which are assigned to roles in Content Server. Roles are assigned to users where they are managed with Oracle WebLogic Server.

Users are assigned groups with the Oracle WebLogic Server Administration Console. When a user logs in to the Content Server instance, the user's groups are mapped to Content Server roles. Oracle WebLogic Server user groups that start with a @ ("at") symbol are mapped to Content Server accounts.

For Oracle WebLogic Server groups to be recognized in Content Server, roles with the exact same names must be created in Content Server and assigned to security groups. If this is not done, the Oracle WebLogic Server groups assigned to users have no impact on users' privileges on Content Server.

Security groups enable you to organize content files into distinct groups that can be accessed only by specific users. For example, files could be assigned to a security group with the name HRDocs, which could represent documents under the Human Resources designation, and could be accessed only by people who worked in the Human Resources department. There are two predefined security groups:

Public: By default, any user can view documents in the Public group without logging in.
Secure: System files are stored in the Secure group and are available only to the system administrator.

18.1.1 Best Practices for Working with Security Groups

Keep these considerations in mind when you define security groups:

Define security groups before anyone checks in files that must be secure.
The number of security groups should be kept at a minimum to provide optimum search performance and user administration performance. If your security model requires more than 50 security classifications, you should enable accounts and use them to control user permissions. This number varies depending on Search Performance and User Admin Performance.
To create instance folders, a user group should have at least admin (RW) access.
Put all files that share the same access into one security group.
Set up a logical naming convention for your security groups. For example, use department names if you are setting up an intranet, and use levels of security (internal, classified, and so forth) if you are setting up an extranet.

For example, Figure 18-1 shows three defined security groups (Public, HRDocs, and EngDocs). They are associated with five users assigned different roles (Admin, Contributor, Guest, Sysadmin, Subadmin) and specific sets of permissions (Read, Write, Delete, Admin).

Figure 18-1 Example of Defining Security Groups

Description of "Figure 18-1 Example of Defining Security Groups"

18.1.2 Performance Considerations

Your user access choices for security groups and roles can affect the following system performance areas:

18.1.2.1 Search Performance

Search performance is affected by the number of security groups a user has permission to access. To return only content that a user has permission to view, the database WHERE clause includes a list of security groups. The WHERE clause either includes all of the security groups the user has permission to access, or it includes all of the security groups the user does not have permission to access. Which approach is taken depends on whether the user has permission to more than 50% or fewer than 50% of the defined security groups.

For example, if 100 security groups are defined, and a user has permission to 10 security groups, the 10 security groups will be included in the WHERE clause. In contrast, for a user with permission to access 90 security groups, the WHERE clause includes the 10 security groups the user does not have permission to access.

Therefore, if a user has permission to almost 50% of the security groups, the search performance is less efficient. If a user has permission to all or none of the security groups, the search performance is more efficient.

18.1.2.2 User Admin Performance

The total number of security groups multiplied by the total number of roles determines the number of rows in the RoleDefinition database table, which affects the performance of the User Admin application for operations involving local users. To determine the approximate time required to perform an operation in the User Admin application, such as adding a security group or changing permission for a role, use the following formula:

(# of security groups) X (# of roles) / 1000 = Time of operation in seconds

For example, using a PC with a 400 MHz processor, 128 MB of RAM, it took approximately 10 seconds to add a security group, or role, or both, using the User Admin application when the RoleDefinition table has 10,000 rows.

As the number of security groups increases, administration performance is affected more than consumer search performance.

18.2 Managing Content Server Groups

The following tasks are used to manage security groups using Content Server.

See Managing Security Information in Administering Security for Oracle WebLogic Server.

18.2.1 Adding a Security Group on Content Server

To create a security group and assign permissions:

Note:

The ^ (caret) is a special character in WebCenter Content and it must not be used in a username, group name, or rule name. The ^ character is parsed by WebCenter Content for the StringUtils class where the character is used for string encoding and decoding.

From the User Admin window, choose Security, then Permissions by Group.
In the Permissions By Group window, click Add Group.
In the Add New Group window, enter a group name and description.
Click OK.
Set permissions for the security group:
1. Select the security group.
2. Select the role to edit.
3. Click Edit Permissions.
4. After enabling the permissions that you want the role to have for the group, click OK to close the Permissions by Group page.

18.2.2 Deleting a Security Group on Content Server

Note:

Never delete a security group or account if it is associated with a content item stored in the Content Server repository.

To delete a security group:

Make sure that no content items are assigned to the security group you want to delete. You cannot delete a security group if content still exists in that security group.
From the User Admin window, choose Security, then Permissions by Group.
In the Permissions By Group window, select the group you want to delete.
Click Delete Group.
Click Yes. The security group is deleted.
After you have deleted the security group, click OK to close the Permissions by Group page.

18.3 Introduction to Content Server Roles and Permissions

A role is a set of permissions (Read, Write, Delete, Admin) for each security group. You can think of a role as a user's job. Users can have different jobs for various security groups. Users can also have different jobs to identify the different teams in which they participate. You can:

Define roles.
Assign multiple roles to a user.
Set up multiple users to share a role.
Set the role's permissions to multiple security groups.

For example, Figure 18-2 shows three roles and the permissions those roles have to the same security group.

Figure 18-2 Example of Roles and Their Permissions

Description of "Figure 18-2 Example of Roles and Their Permissions"

Roles are assigned to one or more users by the system administrator to provide access to the security groups. Figure 18-3 shows the EngUsers role with only Read permission to the HRDocs security group. However, this role provides Read, Write, and Delete permissions to the EngDocs security group. This provides an added measure of security, ensuring that only users who need access to certain documents can modify them.

Figure 18-3 Example of Roles and Security Group Access

Description of "Figure 18-3 Example of Roles and Security Group Access"

18.3.1 Predefined Roles

The following roles are predefined in Content Server:

Roles	Description
admin	The admin role is assigned to the system administrator. By default, this role has Admin permission to all security groups and all accounts, and has rights to all administration tools.
contributor	The contributor role has Read and Write permission to the Public security group, which enables users to search for, view, check in, and check out content.
guest	The guest role has Read permission to the Public security group, which enables users to search for and view content.
sysmanager	The sysmanager role has privileges to access the Admin Server links from the Administration menu in the user interface.

18.3.2 About Permissions

Each role allows the following permissions for each security group: Read (R), Write (W), Delete (D), Admin (A), Standard Annotation (S), Restricted Annotation (T), or Hidden Annotation (H). The permission that a user has to access the files in a security group is the highest permission defined by any of the user's roles. If a user has the guest and contributor roles, where guest is given Read permission and contributor is given Write permission to the Public security group, the user will have Write permission to content in the Public security group. When a user is assigned the Standard Annotation, Restricted Annotation, or Hidden Annotation permission, the Read permission is given by default to that user.

As shown in Figure 18-4, Joe Smith and Ann Wallace have permissions to two security groups:

Joe Smith has Read, Write, and Delete permission to the EngDocs security group, but only Read permission to the HRDocs security group. As a member of the EngUsers role, he has been given Read, Write, and Delete access to Engineering Documents, but only Read access to Human Resource documents.
Ann Wallace has Read, Write, and Delete permission to the HRDocs security group, but only Read permission to the EngDocs security group. As a member of the HRUsers role, she has been given Read, Write, and Delete access to Human Resource documents, but only Read access to Engineering documents.

Figure 18-4 Example of Assigned Permissions

Description of "Figure 18-4 Example of Assigned Permissions"

18.3.3 Predefined Permissions

Each role allows the following permissions to be assigned for each security group:

Permission	Description
Read	Allows viewing documents in the security group.
Write	Allows viewing, checking in, checking out, and getting a copy of documents in the security group. An author who has Write permission in the a security group can change the security group setting of a document.
Delete	Allows viewing, checking in, checking out, getting a copy, and deleting documents in the security group. If the configuration variable AuthorDelete is set to true, and Content Server is configured to use Folders (enabled by the FrameworkFolders component), the author can delete the author's own revisions as long as the author has Read privilege, otherwise the author would need Delete privilege to the content item's security group.
Admin	Allows viewing, checking in, checking out, getting a copy, and deleting files in the security group. If the user has Workflow rights, the user can start or edit a workflow in the security group. The user can check in documents in the security group with another user specified as the Author. As a non-author of a document, the user can change the security group setting of the document if the user has Write permission in the new security group.
Standard Annotation	Allowed to create, modify, and delete standard annotations. An user who can access a document can view the standard annotations on the document.
Restricted Annotation	Allowed to create, modify, and delete restricted annotations. Any user can view restricted annotations on a document if they can access that document.
Hidden Annotation	Allowed to create, view, modify, and delete hidden annotations. Note: Users require this permission to view any hidden annotation on a document even if they can access that document. Redaction can only be of standard or restricted type. A hidden redaction is not supported.

18.4 Managing Content Server Roles and Permissions

Roles and permissions are defined and managed in Content Server. Roles are assigned to user logins, which by default are managed with the Oracle WebLogic Server Administration Console.

The following tasks are used to manage user roles.

18.4.1 Creating a Role in Content Server

To create a role and configure permissions in Content Server:

Note:

From the User Admin window, choose Security, then Permissions by Role.
In the Permissions By Role window, click Add New Role.
In the Add New Role window, enter a Role Name.
- The Role Name is limited to 255 characters. However, you must ensure that the role names are unique in the first 30 characters.
- The following characters are not allowed: spaces, tabs, line feeds, returns, and ; : ^ ? & + " # % < > * ~ |
- Initially, a role is assigned Read (R) permission to the Public security group and no permissions to any other security groups.
Set permissions for the role:
1. Select the role.
2. Select the security group to edit.
3. Click Edit Permissions.
4. Edit the permissions.
5. Click OK and close the Permissions By Role page.

18.4.2 Deleting a Role in Content Server

To delete a role in Content Server:

Make sure that no users are assigned to the role to delete. (You cannot delete a role if any users are assigned to it.)
From the User Admin window, choose Security, then Permissions by Role.
In the Permissions By Role window, select the role to delete.
Click Delete Role.
Click Yes.

18.4.3 Assigning Roles to a User with Oracle WebLogic Server

To assign roles to a user for Content Server, use the Oracle WebLogic Server Administration Console. While roles are defined in Content Server, roles must be assigned to users with the Administration Console. For more information, see the Oracle WebLogic Server Administrator's Guide.

Users also can be assigned groups with the Oracle WebLogic Server Administration Console. For Oracle WebLogic Server groups to be recognized in Content Server, roles with the exact same names as the groups must be created in Content Server and assigned to security groups.

18.4.4 Assigning Roles for a Similar User with Oracle WebLogic Server

To assign roles when creating a user for Content Server that has similar access to that of another user login, use the Oracle WebLogic Server Administration Console. While roles are defined in Content Server, they must be assigned to users with the Administration Console. For more information, see the Oracle WebLogic Server Administrator's Guide.

18.4.5 Adding and Editing Permissions in Content Server

To add permissions to a role or edit existing permissions in Content Server:

From the User Admin window, choose Security, then Permissions by Role.
In the Permissions By Role window, either select an existing role, or add a new role. The permissions associated with the security groups are displayed.
Select an item in the Groups/Rights column.
Click Edit Permissions.
In the Edit Permissions window, specify the permissions to associate with this role and security group. For more information about permissions, see Predefined Permissions.
Click OK.