Defining Administrative Roles

The purpose of this chapter is to help you develop a plan to assign administrative responsibility for managing portal objects.

At the end of this chapter, you should be able to scope the effort involved in deploying the initial administrative objects. You should also be ready to assign administrative responsibility for the initial deployment.

Before you proceed, print Administrative Roles Worksheet. You can use the worksheet to record your assignments and note the activity rights and access privileges for groups of users.

This chapter includes the following topics to help you scope and assign tasks for your deployment effort.

Task	Topic
Learn about access privileges and activity rights.	About Access Privileges and Activity Rights
Draft a role-based group hierarchy.	Creating a Group Hierarchy
Note Activity Rights required for particular roles.	Assigning Activity Rights
Create an administrative object hierarchy.	Defining an Administrative Object Hierarchy
Determine which objects you want to manage through the migration approval process.	Managing Quality through Object Migration

Resource	Description
Consulting Services	Get advice from the experts.
Education Services	Take classes from the experts. To learn how to develop a group hierarchy, enroll in the series of classes developed for ALI administrators.
Knowledge Base	Register and log into the Support Center. Search the Knowledge Base for role- and group-related topics, such as "Roles", "Groups", "Activity Rights", "ACL", and the like.
Administrator Guide and Online Help	Learn how to implement roles by configuring properties for groups and users.

About Access Privileges and Activity Rights

You can manage what users read, select, and modify by assigning access privileges to administrative or content objects (folders) and activity rights to user objects (users and groups).

You delegate administrative responsibility by assigning roles to administrative groups. Generally, roles that include activity rights are held by different people in each department. For example, each department probably has its own community administrator. Keeping the access privileges separate from the activity rights allows you to define activity roles once and then apply them throughout your company, instead of having to define the same set of activity rights for each department. For example, if you want to create a content administrator role, you can create a group with the following activity rights: Access Administration, Create Content Service, Create Job, Create Filter, Create Document Type, and Access Utilities.

You can usually assign access privileges to your existing user groups, because access is generally granted along departmental lines, and, more than likely, your user groups are also along departmental lines. For example, you might give the Marketing group Select access on the Marketing folder and all Marketing objects. Depending on the size of your department, you might also need to create roles for Admin and/or Edit access; if there are only a few people who need Admin or Edit access to an area of the portal, you might want to just change the access for those individual users. You do not need to give creation activity rights (such as Create Portlets) to every role; you only need Edit access on an object to edit the object. Therefore, you create roles that can manage existing objects but cannot create anything.

Creating a Group Hierarchy

Put the most powerful groups at the bottom (the deepest level) of a group hierarchy. Because groups inherit the rights of the parent groups, the groups with most rights are the groups furthest down the group hierarchy. For example, the IT Managers group should be a child group of the IT group, not the other way around. This is especially true of groups with activity rights directly assigned to them. They should be as low in the hierarchy as possible.

In Figure 4-1, the first-level group includes all users in the subdomain. You can configure corresponding access privileges and rights for such users. In the first domain, Community Manager 1 is a sub-group of the Domain Users 1 group and its users have all the rights of the Domain Users group, plus additional privileges required for managing communities. The Content Manager 1.1 and Content Manager 1.2 groups have all the rights of the Domain Users 1 group, plus the rights of the Community Manager 1 group, plus additional privileges for managing content. The lowest group in the hierarchy is the Administrator, who has all rights.

Assigning Activity Rights

Here are a few suggestions for common roles used to assign sets of activity rights.

Role	Suggested Activity Rights
Content/Document Administrator	Access Administration - to access the administration hierarchy Edit Knowledge Directory - to create new document folders Create Content Services - to create new Content Services Create Data Sources - to access secured documents Create Document Types - to force metadata onto documents Create Filters - to automatically manage folders Create Jobs - to run jobs Access Utilities - to approve documents Access Smart Sort - to re-sort entire folders of already categorized documents
Community Creator	Access Administration Create Communities - to create communities Create Community Infrastructure - to create community and page templates
Portlet Creator	Access Administration Create Portlets - to create portlets Create Web Service Infrastructure - to create the remote server and web service to create truly custom portlets
Group/User Creator	Access Administration Create Admin Folders - to make new admin folders to store users Create Experience Definitions - to modify the user experience of users Access Utilities - to create default profiles to apply initial layouts to users Create Authentication Sources - to create authentication sources Create Jobs Create Profile Sources - to apply user information to synchronized users Create Groups - to create groups Create Users - to create users Delegate Rights - to delegate rights to users (create activity groups)

Defining an Administrative Object Hierarchy

The Administrative Object Directory is similar to the Knowledge Directory; it is a hierarchical folder structure (up to 10 levels deep), but it stores administrative objects rather than files.

The folders can store any type of administrative object (for example, Content Services, portlets, or users). Within each folder, objects are automatically grouped by object type to ease management. Each folder is secured, and objects created in that folder default to the ACL of the parent folder.

Start with the end-user hierarchy. Although you can create a hierarchy based on the organizational or management structure, this is often not the best organization for end-users (users who browse the portal rather than manage parts of the portal). End-users can see the administrative hierarchy in a few places in the portal. For example, by default, the Add Portlets and Join Communities pages search the administrative hierarchy for available portlets and communities and try to display a list of objects without showing their parent folders. However, users can choose to browse the hierarchy.

The best thing to do is to start by creating the hierarchy for only communities and portlets (including portlet bundles) and hiding the administrative objects created during installation. For example, you might want to move all objects meant for administrators to a particular folder and restrict access to the folder so that end-users will not see it if they browse the hierarchy.

The organization of the objects meant for administrators can be based on administrative structure or by object type or by topic.

Hide folders that are intended for administrators (as mentioned in the previous bullet).
Organize objects by topic rather than by object type (objects are automatically grouped by type within each folder).
Preset folder ACLs. If your group hierarchy is fairly stable, preset the ACL on Admin folders with both groups and their subgroups. This takes some planning but it will be of great use to portal managers. Since it is easier to remove than add groups and users to the ACL of objects, pre-add as many groups to the ACL of objects folders. When an object is created in that folder, it defaults to the ACL of the folder. If the object is to be restricted to a subset of the folder, the owner of the object can then remove groups from the object. For example, assume all the members of the IT Managers group are members of the IT group. It would be helpful to add both the IT Managers and the general IT group to the ACL of the IT folder. For objects that are meant for just IT Managers, simply remove the general IT group. If only the general IT group was initially added to the parent folder, you would have to remove the general IT group from the object and search for the IT Managers group to add it to the object. If your are constantly adding groups, this might become cumbersome.
Do not always rely on folder ACLs to control access to objects. Remember, technically a user only needs Read access to a portlet if that portlet is already on that user's My Page or community. It is better to set security on the object than the folder.
Always manage by groups. It is always easier to manage by groups than by users, especially because you can put groups in groups. For example, assume IT manages 100 objects. user U is the IT manager. If only user U was added to the ACL of objects then it would be very difficult to also let user X manage IT objects since user X would have to be added individually to all IT objects. If the IT Manager group is added to the ACL of the IT objects, then any user added to that group would inherit the rights of that group.
Start from the top. When you are manipulating folder security for a lot of folders, you should always start from the top. Remember that propagation goes from the top down. Therefore if you change the ACL of a subfolder and then change the ACL of the parent folder and select propagation, the changes you made to the subfolder will be lost. Since propagation is handled by jobs that are automatically created in the Intrinsic Operations folder, you will not see the changes immediately, but the jobs will run and the proper security will be set.

Managing Quality through Object Migration

You can set up a staging system for development, testing, and production deployments and use object migration to move objects from one deployment to another. This allows the ALUI administrator to strictly control who has the ability to create new objects, to test object security and process load, and to make objects available to users only when they are working as planned. For information on object migration, see Using Migration Features to Stage Your Deployment.