This chapter describes the portal conventions for user and group management and provides the steps you take to implement managed access to portal objects. It includes the following sections:
In the portal, a role is not an object, rather a way of thinking about administrative responsibilities. For example, the Knowledge Directory manager role is not an object you define; it relates to administrative responsibilities for those who manage contents of the Knowledge Directory.
A group is an object you configure. A group contains other groups and users, as well as any activity rights assignment for group members. A group can have static membership and membership that changes dynamically based on properties of users' profiles or their memberships in other groups.
A user is an object that corresponds to a user account. You configure new users based on profile templates, known as default profiles. Profiles are objects you configure. They contain information about users, such as name, job title, and so forth.
Activity rights determine which portal objects a user can create and which portal utilities a user can execute to create or modify portal objects.
Access privileges determine which portal objects a user can browse or edit, which objects appear in search results, and which can be added to My Pages and Community pages.
You implement security for portal access and portal activities in a manner similar to implementing security for other network, domain, and system objects—by managing a hierarchy of the objects that determine access privileges and activity rights.
The default portal installation creates the following group, user, and profile objects, with default access privileges and activity rights.
As a portal administrator, one of your first tasks is to delegate and share the administrative role by defining the access privileges and activity rights for administrative groups, and then assigning to these groups the users and groups of users that are the basis for your deployment plan.
Caution: | By default, you can log in to the administrative portal as Administrator with no password. If the default Administrator password has not yet been changed, you should do so as soon as possible. Make sure that you document the change and inform the appropriate portal administrators. |
Before you begin the task of managing portal groups and users, familiarize yourself with your deployment plan. If you plan to leverage group configurations from an existing Active Directory or LDAP authentication source, you might proceed differently from an administrator who plans to manage portal groups using the default portal authentication source. For example, if you plan on using an LDAP authentication source, you might import users, groups, and profile information first and then proceed with configuration of role-based group rights assignments. If you plan to add users to your portal by invitation and manage them through the portal authentication source, you might create the groups first and then add the invited users to these groups.
For detailed information on developing a plan to manage the administrative roles, groups, and users for your enterprise portal, refer to the Deployment Guide for BEA AquaLogic User Interaction G6.
The topics in this chapter describe the following basic steps you take to add users and to manage user access privileges and activity rights:
Before you create portal groups, you should become familiar with the definition and scope of the administrative tasks you plan to delegate, and you should develop a plan for assigning the responsibilities and rights for these administrative roles to groups of users. In terms of portal objects, roles are not objects that you configure. Roles are associations between groups and activity rights. In Configuring Groups, you configure group objects to enable administrative roles. In Adding Users, you add child groups and users to the groups. This section describes the activity rights that are defined by default during installation. Use the information provided in this section to develop your plan to delegate specific activity rights to the administrative groups and users you configure in the sections that follow.
Table 3-2 summarizes the activity rights that are defined by default in the portal. If you encounter cases that require rights not covered by the defaults, you can create custom activity rights. For information on creating custom activity rights, see Creating Custom Activity Rights.
Table 3-2 also provides an example map between activity rights and administrative roles. Roles are related to the specific activity rights required to perform a job function. In the example, the role called Content Manager provides the activity rights required to populate the portal with document records crawled from remote content sources: Access Administration, Access Utilities, Create Admin Folders, Create Content Types, Create Content Crawlers, Create Content Sources, and Create Jobs. A separate role called Knowledge Directory Manager provides the activity rights required to create Knowledge Directory structure: Access Smart Sort, Access Unclassified Documents, Access Utilities, Advanced Document Submission, Create Filters, Create Folders, Edit Knowledge Directory, and Self-Selected Experts. Although some users might fill both roles, others might not. By creating two separate roles, you can assign rights for one or both roles to one or many groups.
Use Table 3-2 to create your own map that delegates administrative rights and responsibilities to roles.
You can also create custom portal activities. For example, if you have an inventory control system accessed through the portal and only certain users are allowed to edit it, you can create an Edit Inventories activity. You can then create inventory-control portlets that verify whether a user has the correct activity right prior to receiving access to the portlet.
To create, modify, or delete custom portal activity rights:
This section provides procedures for creating the portal groups to which you grant role-specific activity rights. Before you perform the task of creating portal groups, make sure you have created a plan to share portal administration responsibilities, following the guidelines in the Deployment Guide for BEA AquaLogic User Interaction G6 and the overview of roles, groups, and users in About Portal Roles, Groups, Users, and Profiles.
If you plan to import users and groups from an existing authentication source, such as LDAP or Active Directory, you might want to import them first and then follow the procedures in this section to add users to groups. For information on importing users and groups from an authentication source, see Importing Users and Groups from Authentication Sources.
You may want to have users automatically added to, or removed from, groups based on properties in their user profiles. For example, you may want to give users access to a community based on their location, title, department, or any other property in their profile. Because some properties can change frequently, you can set up dynamic group membership rules so that when selected properties change, users are automatically added to, or removed from, a group.
To create dynamic group membership rules:
If you add or change dynamic membership rules for a group, dynamic members are updated for this group after you click Finish. Otherwise, dynamic memberships are updated for all groups as part of a job (the Dynamic Membership Update Agent). When user profile data changes, the resulting dynamic group membership changes are updated as part of this job. For more information, see About Jobs.
Default profiles are templates for new users. Default profiles configure the initial My Account settings, the name and number of My Pages, and the layout of the portlets on those My Pages.
Before you add users to your portal, configure the default profiles you want to apply to the users you will add. For example, if all technical writers should have certain mandatory portlets on their default My Pages, configure a default profile for this purpose and apply the profile to these users when you add them.
Create multiple profiles to apply to the different types of users you anticipate.
To configure default profiles:
To edit the layout of a default profile:
This section provides procedures for adding users to the portal. When you add users, you configure group memberships and apply a default profile. This section describes the following options for adding users to the portal:
This section provides procedures for adding the users and groups that are already defined in your enterprise in existing authentication sources, such as Active Directory, LDAP, or Windows domain sources. This section includes the following topics:
For information on installing AquaLogic Interaction Identity Services on a remote server host computer, refer to the product documentation provided with your software.
An authentication source enables you to import users, groups, and group memberships into the portal from an external authentication server. After you have imported the users, the authentication source authenticates portal logins.
If you plan to import users with an AquaLogic Interaction Identity Service, such as AquaLogic Interaction Identity Service - LDAP or AquaLogic Interaction Identity Service - Active Directory, follow the product documentation provided with that software instead of the procedures in this guide.
The following table describes the steps you take to import users, groups, and group memberships from a remote authentication server.
|
|
Before you can run the synchronization job, you must associate the folder that contains the job with an Automation Service. For information on associating folders with an Automation Service, see Automating Administrative Tasks. |
|
A profile source enables the portal to use an external source to define user properties that can be searched by portal users, forwarded to portlets to authenticate portlet access, or for other purposes.
If you plan to import profile information with an AquaLogic Interaction Identity Service, such as AquaLogic Interaction Identity Service - LDAP, follow the product documentation provided with that software instead of the procedures in this guide.
The following table describes the steps you take to import user properties from an external source.
|
|
Before you can run the job, you must associate the folder that contains the job with an Automation Service. For information on associating folders with an Automation Service, see Automating Administrative Tasks. |
|
If your enterprise does not use third-party authentication sources, you can use a portal utility to create users. Users you create with the portal utility, users who self-register, and users added by invitation are included in the AquaLogic Interaction Authentication Source.
The portal enables users to create their own accounts by clicking Create an Account on the Login page. These users are stored in the portal's Default Experience Definition folder and are are included in the AquaLogic Interaction Authentication Source.
Users who self-register are granted access privileges based on the settings for the default profile named Default Profile. Based on this security, users can personalize their views of the portal with My Pages, portlets, and community memberships, and can view portal content.
Invitations allow you to direct potential users to your portal, making it easy for them to create their own user accounts and letting you customize their initial portal experiences with content that is of particular interest to them.
You should create a single invitation for all potential users who should be added to the same portal groups and should see the same communities, portlets, and My Pages when they first log in to your portal.
To accept the invitation, the user clicks the link included in the e-mail and follows the directions to create a new user to log in to the portal. When the user logs in, the portlets, content, and communities specified in the invitation are displayed to the new user.
Users added by invitation are included in the AquaLogic Interaction Authentication Source.
After creating an invitation, you need to send the invitation.
This section provides procedures for managing user profiles and user accounts. It includes the following topics:
To delete a user whose account is locked:
Profile information, such as name and job title, is stored with user objects as properties. You can use the User Profile Manager to specify which properties are sent to portlets when requested.
The values for specific properties are set either by the user on the Edit User Profile screen or by a profile source.
To specify which user properties are sent to portlets:
The portal logs user activities, which allows you to query for actions taken by particular users, actions taken on a particular administrative object, or actions taken within a specified time period.
Note: | You should configure activity logging to adequately meet the security auditing needs of your portal deployment and then implement procedures for periodically reviewing the audit records. |
To configure user activity auditing:
The Audit Log Management agent moves audit messages from the portal database into a collection of archive files and deletes old archive files based on the settings you configure in the Audit Manager. The Audit Log Management agent runs in the Audit Log Management Job, created upon installation and stored in the Intrinsic Operations folder. By default, this job runs daily. For information on configuring the Audit Log Management agent, see Running Portal Agents.
To query the database for audit entries:
When you configure user activity auditing, you can specify the frequency with which audit messages are deleted automatically.
To delete messages and archives immediately:
You lock user accounts to disable access to the portal. You can configure automatic locking based on repeated failed login attempts, or you can lock user accounts any time with the User Editor.
To configure account locking for failed login attempts:
Your individual security needs will determine what settings to use for automatic account locking. For example, to meet a strength of password function rating of SOF-basic as defined in the Common Criteria for Information Technology Security Evaluation, Version 2.3, August 2005 (found at http://niap.bahialab.com/cc-scheme/cc_docs/), you might set the following values:
The lock on accounts that are locked automatically will eventually expire, but you can remove account locks with the Release Disabled Logins utility or the User Editor.
The following table describes how to unlock user accounts that have been locked in particular ways.
|
|
You can enable users to access existing Web applications through the portal. For example, users may need to access an employee benefits system. If they access the benefits system through the portal, they do not have to enter their login credentials separately for that application, and can continue to have the convenience of the portal context, personalization, and navigation.
To manage user credentials, you can create a lockbox for each application the user needs to access through the portal. Then, users enter their credentials for each lockbox in their My Account settings.
For more information on integrating applications, see Using Portlets to Access Existing Web Applications.
To supply login credentials for lockboxes, users do the following:
After you have imported users and groups into the portal, you can configure access control lists (ACL) to manage privileges to folders in the Administrative Objects Directory. You can also set access control lists for objects within folders. The default portal installation includes the following folders in the Administrative Objects Directory.
Users in the Administrators group have full access to all portal objects. Other users can be assigned the following access privileges:
By default, newly created objects inherit the ACL configuration of their parent folder.
The following table describes the minimum access required to perform actions on an object.
The Everyone group always has Read access to the following types of portal objects:
To set the ACL on folders in the Administrative Objects Directory:
By default, newly created objects inherit the ACL configuration of their parent folder. If subfolders require different configuration from their parent, modify the ACL for the subfolders as needed. You can also set the security on objects within a folder by editing the Security page in that object's editor.
Experience definitions define the user experience by controlling the branding, styles, navigation, and features of the portal pages the user sees. You can set up rules to evaluate which experience definition any given user should see. The rules can be based on the URL the user uses to access the portal, the user's IP address, the user's group memberships, or when the user navigates to a specific community. For more information, see Configuring Experience Definitions.