# Deployment Planning

# Defining Administrative Roles

This chapter provides a high level overview of administrative roles.

The purpose of this chapter is to assist in developing a plan to assign administrative responsibility for managing portal objects.

## Access Control Lists and Activity Rights

What users read, select, and modify in the portal is controlled by access control lists and activity rights.

### Access Control Lists

An access control list (ACL) is a list of privileges associated with each folder or object in the portal. You can add users and groups to the ACL of an object in order to grant permission to perform certain tasks, such as viewing or modifying the object.

For details on using ACLs in the portal, see Setting User Access Privileges in the Administrator Guide for AquaLogic Interaction.

### Activity Rights

You can associate activty rights with users and groups to allow users to perform specific tasks within the portal. For example, the Access Administration activity right allows a user to see the Administration tab in the portal and to access the administrative object hierarchy. There are a number of activity rights built into the portal. You can also create custom activity rights.

For more information on activity rights, including a full list of activity rights built into the portal, see Delegating Activity Rights in the Administrator Guide for AquaLogic Interaction.

## Creating a Group Hierarchy

When creating a group hierarchy, begin with the users with the least rights and work towards the most powerful users. A group inherits the rights of its parent group, so the broadest groups with the least rights should be parent to more specific groups with greater rights.

For example, the engineering department creates an Engineer group (for all members of the department). The QA subset of the engineering department requires special access to certain bug tracking software, so a QA group should be created with the Engineer group as a parent. Administrative tasks on the bug tracking software is restricted to QA managers, so a group inheriting from the QA group is created for QA managers.

The Everyone group is the parent of all groups. All members of the Everyone group have the right to read and access their own profile.

The Administrator group is a child of all groups and has access to everything.

## Assigning Activity Rights

The following table provides suggested activity rights for common roles found in an AquaLogic User Interaction deployment:

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 a hierarchical folder structure that stores administrative objects.

Administrative objects include such objects as content services, portlets, and users. Each folder groups objects by object type. Each object’s permissions default to the ACL of the folder.

For details on the Administrative Object Directory, see the Administrator Guide for AquaLogic Interaction.

The following guidelines can assist you in planning an administrative object hierarchy:

- Start with the end-user hierarchy rather than an organizational or management structure. 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 display a list of objects without showing their parent folders.

Start by creating the hierarchy for communities and portlets (including portlet bundles) only and hide the administrative objects created during installation. For example, 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 should be based on administrative structure or topic.

- Organize objects by topic rather than by object type. Objects are automatically grouped by type within each folder.
- Set ACLs for folders as early as possible. Objects created in a folder inherit the ACL of the folder. By planning access control early, you simplify managing object security.
- Manage user access by managing groups. Assigning a user to a group with permissions to a set of objects is easier than assigning each user to each object in the set.

## Managing Quality through Object Migration

Creating a staging system for development and testing allows the AquaLogic User Interaction administrator to test object security. For information on object migration, see Migration and Staging.