Skip Headers
Oracle® Fusion Middleware Administering Oracle WebCenter Content
11g Release 1 (11.1.1)

Part Number E26692-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

19 Managing Security Groups, Roles, and Permissions

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

This chapter includes the following topics:

19.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:

19.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.

  • 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 19-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 19-1 Example of Defining Security Groups

Description of Figure 19-1 follows
Description of "Figure 19-1 Example of Defining Security Groups"

19.1.2 Performance Considerations

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

19.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.

19.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.

19.2 Managing Content Server Groups

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

For information on managing groups, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

19.2.1 Adding a Security Group on Content Server

To create a security group and assign permissions:

  1. From the User Admin window, choose Security, then Permissions by Group.

  2. In the Permissions By Group window, click Add Group.

  3. In the Add New Group window, enter a group name and description.

  4. Click OK.

  5. 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.

19.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:

  1. 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.

  2. From the User Admin window, choose Security, then Permissions by Group.

  3. In the Permissions By Group window, select the group you want to delete.

  4. Click Delete Group.

  5. Click Yes. The security group is deleted.

  6. After you have deleted the security group, click OK to close the Permissions by Group page.

19.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:

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

Figure 19-2 Example of Roles and Their Permissions

Description of Figure 19-2 follows
Description of "Figure 19-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 19-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 19-3 Example of Roles and Security Group Access

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

19.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 in Content Server.


19.3.2 About Permissions

Each role allows the following permissions for each security group: Read (R), Write (W), Delete (D), or Admin (A). 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.

As shown in Figure 19-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 19-4 Example of Assigned Permissions

Description of Figure 19-4 follows
Description of "Figure 19-4 Example of Assigned Permissions"

19.3.3 Predefined Permissions

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

Permission Description

Read

Allowed to view documents in the security group.

Write

Allowed to view, check in, check out, and get a copy of documents in the security group. The author can change the security group setting of a document if the author has Write permission in the new security group.

Delete

Allowed to view, check in, check out, get a copy, and delete documents in the security group. The configuration setting AuthorDelete=true adds delete permission to all security groups to which the author has Write permission.

Admin

Allowed to view, check in, check out, get a copy, and delete 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 is allowed to 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.


19.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.

19.4.1 Creating a Role in Content Server

To create a role and configure permissions n Content Server:

  1. From the User Admin window, choose Security, then Permissions by Role.

  2. In the Permissions By Role window, click Add New Role.

  3. In the Add New Role window, enter a Role Name.

  4. 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.

19.4.2 Deleting a Role in Content Server

To delete a role in Content Server:

  1. Make sure that no users are assigned to the role to delete. (You can not delete a role if any users are assigned to it.)

  2. From the User Admin window, choose Security, then Permissions by Role.

  3. In the Permissions By Role window, select the role to delete.

  4. Click Delete Role.

  5. Click Yes.

19.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.

19.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.

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.

19.4.5 Adding and Editing Permissions in Content Server

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

  1. From the User Admin window, choose Security, then Permissions by Role.

  2. 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.

  3. Select an item in the Groups/Rights column.

  4. Click Edit Permissions.

  5. In the Edit Permissions window, specify the permissions to associate with this role and security group. For more information about permissions, see Section 19.3.3.

  6. Click OK.