19 Managing Accounts

This chapters provides information on Content Server accounts, which are defined and managed in Content Server. Account permissions are assigned to user logins with the Oracle WebLogic Server Administration Console.

This chapter includes the following topics:

• Introduction to Content Server Accounts

• Managing Content Server Accounts

• A Content Server Accounts Case Study

19.1 Introduction to Content Server Accounts

Accounts give you greater flexibility and granularity in your security structure than security groups alone provide. Accounts and account permissions are assigned to users with the Oracle WebLogic Server Administration Console, and the server maps groups to Content Server roles and accounts. An account also can be assigned to each content item. To access a content item that has an account assigned to it, the user must have the appropriate permission for the account.

Oracle WebLogic Server user groups that start with a @ ("at") symbol are mapped to Content Server accounts.

Note:

If you enable accounts and use them, then later choose to disable accounts, you can have the perception of losing data. The repository remains intact. However, if you make certain changes to the security model, then you also must update the users' access rights so they can continue to access the secure content.

To avoid this situation, examine your requirements and the WebCenter Content security model of groups and accounts to determine what would best match your needs. Unless you are certain that you want to use accounts, do not enable them.

Some ways accounts can be created:

• The Content Server administrator creates predefined accounts using the User Admin tool. For details, see Creating Predefined Accounts in Content Server.

• A user administrator creates an account while checking in content. For details, see Creating Accounts When Checking In Content in Content Server.

Note:

It is recommended not to use stopwords in account names. Stopwords are words that a search engine filters out or ignores in a search query when they are combined with other keywords. When a search on the account names is conducted using the OracleTextSearch component, returned search results may be adversely affected if the query contains stopwords. For more detailed information about using stopwords or for instructions on how to remove them, refer to the Oracle Text Reference document.

You must enable accounts to use them. For more information, see Enabling Accounts in Content Server.

19.1.1 Accounts and Security Groups

When accounts are used, the account becomes the primary permission to satisfy before security group permissions are applied. You can also think of a user's access to a particular document as the intersection between their account permissions and security group permissions.

For example, the EngAdmin role has Read, Write, Delete, and Admin permission to all content in the EngDocs security group. A user is assigned the EngAdmin role, and is also assigned Read and Write permission to the AcmeProject account. Therefore, the user has only Read and Write permission to a content item that is in the EngDocs security group and the AcmeProject account.

Figure 19-1 shows the intersection of the AcmeProject account and EngDocs security group permissions.

Figure 19-1 Example of Security Group Permissions

Description of "Figure 19-1 Example of Security Group Permissions"

Security group permissions are ignored if the account does not permit access to any content. Remember that the account acts as a filter that supersedes the permissions defined by the user's roles.

19.1.2 Hierarchical Accounts

Accounts can be set up in a hierarchical structure, which enables you to give some users access to entire branches of the structure, while limiting permissions for other users by assigning them accounts at a lower level in the structure. Figure 19-2 shows a typical hierarchical account structure.

Figure 19-2 Example of Hierarchical Account Structure

Description of "Figure 19-2 Example of Hierarchical Account Structure"

Important:

Because account names form part of the directory path for the URL of a content item, account names cannot exceed 30 characters.

• If you use slashes to separate the levels in account names (for example, Eng/Acme/Budget), Content Server creates a weblayout directory structure according to your account structure. (However, each actual directory will not be created until a content item is assigned to the account during the check-in process.) Each lower level in the account name becomes a subdirectory of the upper level, with an @ symbol prefix to indicate that the directory is an account level.

  Important:

  When using an embedded LDAP server, do not use the slash. The usage of back slashes (/) and forward slashes (\) is not recommended for security groups when using an Oracle WebLogic Server Console.

• If a user has permission to a particular account prefix, they have access to all accounts with that prefix. For example, if you are assigned the Eng/XYZ account, you have access to the Eng/XYZ account and any accounts that begin with the Eng/XYZ prefix (such as Eng/XYZ/Schedule and Eng/XYZ/Budget).

  Important:

  The account prefix does not have to include slashes. For example, if you have accounts called abc, abc_docs, and abcdefg, all users who have access to the abc account will have access to the other two accounts as well.

To handle the security structure depicted above, you would create the following accounts:

• Eng

• Eng/Acme

• Eng/XYZ

• Eng/Acme/Schedule

• Eng/Acme/Budget

• Eng/XYZ/Schedule

• Eng/XYZ/Budget

Figure 19-3 Example of a Security File Structure

Description of "Figure 19-3 Example of a Security File Structure"

19.1.3 Performance Considerations

Consider the following performance issues when using accounts in your security model:

• Theoretically, you can create an unlimited number of accounts without affecting Content Server performance. A system with over 100,000 pieces of content has only limited administration performance problems at 200 accounts per person; however, there is significant impact on search performance with over 100 accounts per person. (Note that these are explicit accounts, not accounts that are implicitly associated with a user through a hierarchical account prefix. A user can have permission to thousands of implicit accounts through a single prefix.)

• For performance reasons, do not use more than approximately 50 security groups if you enable accounts.

• Ensure that your security groups and accounts have relatively short names.

19.1.4 External Directory Server Considerations

Accounts are available whether or not your Content Server instance is integrated with an external directory server (such as the default Oracle WebLogic Server). When you use accounts with an external directory, ensure that you follow these guidelines:

• Set up a global group with the appropriate users in it to match the account.

• Associate group names to either a role or an account by configuring mapping prefixes.

19.2 Managing Content Server Accounts

The following tasks are involved in managing accounts.

• Enabling Accounts in Content Server

• Creating Predefined Accounts in Content Server

• Creating Accounts When Checking In Content in Content Server

• Deleting Predefined Accounts in Content Server

• Assigning Accounts to a User with Oracle WebLogic Server

19.2.1 Enabling Accounts in Content Server

To enable accounts in the Content Server instance:

Important:

If you enable accounts and use them, then choose to disable accounts, you can have the perception of losing data. The repository remains intact. However, if you make certain changes to the security model, then you also must update the security settings for users so they can continue to access the content.

1. In the Content Server portal, choose Administration, then Admin Server, then General Configuration.
2. On the General Configuration page, select Enable Accounts.
3. Save the changes.
4. Restart the Content Server instance.

Alternately, you can add the following line to the Additional Configuration Variables field on the General Configuration page, which shows the contents of the DomainHome/ucm/cs/config/config.cfg file:

UseAccounts=true

Save the changes, and restart the Content Server instance.

19.2.2 Creating Predefined Accounts in Content Server

To create a predefined account on the Content Server instance:

1. From the User Admin page, choose Security, then Predefined Accounts.
2. In the Predefined Accounts window, click Add.
3. In the Add New Predefined Account window, add the name of the new account. Keep the names short and consistent. For example, set up all of your accounts with a three-letter abbreviation by location or department (MSP, NYC, etc.). Account names can be no longer than 30 characters, and the following are not acceptable: spaces, tabs, line feeds, carriage returns, and the symbols : ; ^ ? : & + " # % < > * ~.
4. Click OK.
5. If you already have content checked in to Content Server repository and you are using a database with full text indexing, rebuild your search index.

   If you are using only the metadata database search indexer engine, you do not need to rebuild your search index.

19.2.3 Creating Accounts When Checking In Content in Content Server

Generally, you should create predefined accounts rather than creating an account during content check-in. For more information about predefined accounts, see Creating Predefined Accounts in Content Server.

To create an account at the time you check in a content item, you must have User Admin rights:

1. Display the Content Check In Form page.
2. Enter all required and optional information.
3. Type an account name in the Account field.
4. Click Check In. The new account is assigned to the content item.

Note:

If you have write (W) privileges to an account, you can create another account with this account as a prefix while checking in a content item. For example, if you have write privileges to the br account, then you can create the brown account and associate it with a content item during check-in.

19.2.4 Deleting Predefined Accounts in Content Server

You can delete an account even if content with that account still exists. The account value will remain assigned to the content item, but will be considered a user-defined account.

Important:

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

To delete a predefined account in the Content Server instance:

1. From the User Admin page, choose Security, then Predefined Accounts.
2. In the Predefined Accounts window, select the account to delete.
3. Click Delete. The account is deleted immediately.

19.2.5 Assigning Accounts to a User with Oracle WebLogic Server

To assign an account to a user, use the Oracle WebLogic Server Administration Console to create a group and then assign it to one or more users. The group name must start with the @ sign and end with permissions delimited by an underscore. The following example creates a group named testaccount and assigns it Read, Write, and Delete permissions: @testaccount_RWD. You must also change the JpsUserProvider and ensure an underscore is in the Accounts Permissions Delimiter field. For more information about JpsUserProvider, see When to Use a JpsUser Provider.

Accounts assigned to a user on Oracle WebLogic Server are mapped to the Content Server instance. See Create users in Oracle WebLogic Server Administration Console Online Help.

19.3 A Content Server Accounts Case Study

In this example, Xalco is a worldwide software company with offices in London, New York, and Paris. They have a Content Server instance hosted in the London office, with access from the other offices through the corporate WAN. At the same time, Xalco is replicating some files out to an area of their public website. Initially, the Sales and Finance departments at each location want to use their instance to publish files. The New York office is small and has no Sales department.

The following sections provide sample information for the Xalco case study:

• Xalco Security

• Xalco Accounts

• Xalco Roles

• Roles and Permissions Table

• Roles and Users Table

• Accounts and Users Table

19.3.1 Xalco Security

• Xalco staff and security levels:

  • London: David Smith, Worldwide CFO, and Jim McGuire, UK Sales Manager

  • New York: Catherine Godfrey, Regional Finance Manager

  • Paris: Helene Chirac, Finance Clerk (Europe)

• Xalco levels of security clearance (security groups) for Xalco content:

  • Public: Files suitable for consumption by members of the public (public content is replicated to the Xalco website)

  • Internal: Files which have unrestricted access internally, but are not suitable for public consumption

  • Sensitive: Files which are commercially sensitive, and restricted to middle managers and above

  • Classified: Highly-sensitive files, suitable only for board members

• Xalco staff access:

  • David Smith: As Worldwide CFO, he requires full access to all files held in the instance.

  • Jim McGuire: As UK Sales Manager, he must have full control of Sales files in London, and have visibility of sales activities in Paris. As a manager, he has clearance to the Sensitive level.

  • Helene Chirac: Based in the Paris office, she must view only files relating to Finance in Europe, and she has clearance only to the Internal level.

  • Catherine Godfrey: As a Regional Finance Manager based in New York, she must contribute Finance files for New York and view all other Finance documents. As a manager, she has clearance to Sensitive level.

19.3.2 Xalco Accounts

Access varies by location and job function, so this is reflected in the account structure:

• London has Finance and Sales departments, so it needs two accounts:

  • London/Finance

  • London/Sales

• New York has only a Finance department:

  • NewYork/Finance

• Paris has both Finance and Sales departments:

  • Paris/Finance

  • Paris/Sales

This results in three top-level accounts (London, NewYork, Paris) and five lower-level accounts.

19.3.3 Xalco Roles

Two roles must be created for each security group (one for Consumers and one for Contributors)

• PublicConsumer

• PublicContributor

• InternalConsumer

• InternalContributor

• SensitiveConsumer

• SensitiveContributor

• ClassifiedConsumer

• ClassifiedContributor

19.3.4 Roles and Permissions Table

To give specific users the ability to start workflows, you would need to add Admin permission and Workflow rights to the Contributor role.

Role	Public	Internal	Sensitive	Classified
PublicConsumer	R
PublicContributor	RWD
InternalConsumer		R
InternalContributor		RWD
SensitiveConsumer			R
SensitiveContributor			RWD
ClassifiedConsumer				R
ClassifiedContributor				RWD

19.3.5 Roles and Users Table

Role	David Smith	Helene Chirac	Jim McGuire	Catherine Godfrey
PublicConsumer		X
PublicContributor	X		X	X
InternalConsumer		X
InternalContributor	X		X	X
SensitiveConsumer
SensitiveContributor	X		X	X
ClassifiedConsumer
ClassifiedContributor	X		X	X

19.3.6 Accounts and Users Table

It would be sufficient to give David Smith RWDA permission on London, New York, and Paris accounts.

Account	David Smith	Helene Chirac	Jim McGuire	Catherine Godfrey
London/Finance	RWDA	R		R
London/Sales	RWDA		RWDA
NewYork/Finance	RWDA			RW
Paris/Finance	RWDA			R
Paris/Sales	RWDA		R