Accounts and Security Groups Hierarchical Accounts

Managing Security and User Access 5-43 There are several ways accounts can be created: ■ The system administrator creates predefined accounts using the User Admin tool. See Section 5.5.2.2, Creating Predefined Accounts on Oracle Content Server. ■ A user administrator creates an account while checking in content. See Section 5.5.2.3, Creating Accounts When Checking In Content on Oracle Content Server. You must enable accounts to use them. For more information, see Section 5.5.2.1, Enabling Accounts on Oracle Content Server.

5.5.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 users 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. 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 Oracle UCM 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. 5-44 Oracle Fusion Middleware System Administrators Guide for Oracle Content Server Figure 5–5 shows the intersection of the AcmeProject account and EngDocs security group permissions. Figure 5–5 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 users roles.

5.5.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 5–6 shows a typical hierarchical account structure. Figure 5–6 Example of Hierarchical Account Structure ■ If you use slashes to separate the levels in account names for example, EngAcmeBudget, the Oracle Content Server system creates a weblayout Important: Because account names form part of the directory path for the URL of a content item, account names cannot exceed 30 characters. Managing Security and User Access 5-45 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. ■ 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 EngXYZ account, you have access to the EngXYZ account and any accounts that begin with the EngXYZ prefix such as EngXYZSchedule and EngXYZBudget. To handle the security structure depicted above, you would create the following accounts: ■ Eng ■ EngAcme ■ EngXYZ ■ EngAcmeSchedule ■ EngAcmeBudget ■ EngXYZSchedule ■ EngXYZBudget 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. 5-46 Oracle Fusion Middleware System Administrators Guide for Oracle Content Server Figure 5–7 Example of a Security File Structure

5.5.1.3 Performance Considerations