2 Planning a User and Group Strategy

Developing a plan to structure your users and groups can save you time later during other phases in the portal life cycle. You must determine where your existing user and group information is stored, how to retrieve this information, if you want to allow users to self-register, and if you will need to add new users to your portal,

You must also determine if you want to store and retrieve user profile information to use in personalization, and if you need to encrypt that user data. You should consider what each group can see or do in your portal, and plan your roles accordingly. If you decide you want to be able to edit user profile information later, you must configure the user store to be writable.

This chapter includes the following sections:

Section 2.1, "Developing a User and Group Management Strategy"
Section 2.2, "Planning Your Groups and Group Hierarchy"
Section 2.3, "Working with a User Store"
Section 2.4, "Planning Data Encryption"
Section 2.5, "Upgrading Users and Groups from Portal 8.1"
Section 2.6, "Designing Users and Groups for Optimal Performance"

2.1 Developing a User and Group Management Strategy

You should plan your role structure at the same time you plan your strategy for users and groups. Making groups role-based to control what each group can do and see in your portal will save you time later.

Use the following steps as guidelines to develop a user and group strategy:

Plan the structure of your groups and subgroups. If your users are located in an external user store and it contains groups, you can bring those existing groups into WebLogic Portal. See Section 2.2, "Planning Your Groups and Group Hierarchy" for more information on categorizing groups and users. Plan the roles for your groups (see the Oracle Fusion Middleware Security Guide for Oracle WebLogic Portal for more information on roles).
Determine where your users are stored and how to access them. Users can be stored in an internal user store (the default RDBMS user store) or in an external user store. For a detailed description of authentication providers and user stores, see Section 1.1.3, "Accessing Users." Determine if you want to encrypt sensitive user data stored in property sets; see Section 2.4, "Planning Data Encryption" and Section 5.1, "Creating a User Profile."
Decide if you will create groups and add users programmatically or if you will use the Administration Console. You can use the WebLogic Scripting Tool to retrieve large numbers of existing users and groups. For instructions, see Oracle Fusion Middleware Oracle WebLogic Scripting Tool. You can also create JSP tags and controls that let users register themselves when they go to your portal application.
If necessary, you can perform the following tasks with the Administration Console or with the Server Administration Console:
1. Create groups and subgroups
2. Add users
3. Add users to groups
For instructions on creating groups and users in the Administration Console, see Chapter 8 and Chapter 9.
Determine if you want to collect and integrate information about users (user profile properties) into your portal. You can use user profile information to target users with personalized content, e-mails, pre-populated forms, and discounts based on the rules you set up. Personalized content can also help guide your users through a process in your portal. For instructions, see Chapter 5 and Chapter 10.
If user profile properties are stored externally, create a UUP to retrieve additional user profile information from the external user stores. You can use the properties to define rules for personalization, delegated administration, and visitor entitlement. For more information on when to use UUP, see Section 2.3.3, "Planning to Use a UUP." For instructions on setting up UUP, see Chapter 6.
After your users and groups appear in the Administration Console, you can place users and groups in roles for delegated administration and assign visitor entitlement. If you are using more than one user store, you might have a group in one user store with a name that is the same as a group in another user store. When you set delegated administration on a group, an administrator in that delegated administration role can manage that group in all providers that contain that group (if the administrator also has delegated administration rights to those other providers). See the Oracle Fusion Middleware Security Guide for Oracle WebLogic Portal for instructions on assigning roles and entitlement.

2.2 Planning Your Groups and Group Hierarchy

You can structure your users into groups and subgroups that look like your organization, which makes it easier to manage users. A group can be a related collection of users, such as a department, team, or regional office. A user can belong to more than one group, and groups can belong to other groups. Plan the roles you plan to associate with each group, to control what each group can see and do.

If you are using an external user store and it contains groups, you can build a group hierarchy tree to retrieve its group structure and view it in the Administration Console. See Chapter 8 for instructions.

Administrators can also create and change a group profile, which is a schema that determines the data you collect and store about a specific group of users. The properties in the group profile contain information about the group that is stored in editable fields in the Administration Console.

You can edit properties for groups, but users belonging to those groups do not automatically inherit the group properties you specify. If a user belongs to two groups, for example, and you have edited each group's properties, you must specify which set of group properties the user should inherit. For more information, see Chapter 8.

After you determine your group structure, you can programmatically create, move, and delete groups in or the Administration Console.

After you create your groups, you can tie the groups to roles and visitor entitlement to control what users see and experience in your portal.

This section contains the following topics:

Section 2.2.1, "Organizing Users into Groups"
Section 2.2.2, "Using an Existing Group Structure"

2.2.1 Organizing Users into Groups

For instructions on putting users into groups, see Section 4.3, "Placing Users in Groups" and Section 9.3, "Placing Users in Groups."

The Everyone group is a built-in group in Administration Console that you cannot modify. All users, including anonymous users, belong to this group.

The first step in setting up your groups is to determine your group hierarchy. For example, you might have a top-level group called AllEmployees that contains all of the employees in your company. The AllEmployees group might then contain other groups, each of which contains just the employees of offices in different geographic locations.

This categorization is shown in the following example:

AllEmployees (group containing all employees)

NewYork (group containing employees in New York)
- Executive
- Marketing
- Human Resources
- Sales
SanFrancisco (group containing employees in San Francisco)
Seattle (group containing employees in Seattle)
Denver (group containing employees in Denver)

When you create a group, you create an empty group to which you can add an infinite number of users. You can then classify the users in the group by mapping the group to an entitlement role; see the Oracle Fusion Middleware Security Guide for Oracle WebLogic Portalr instructions.

You can use the Administration Console to add a user to a group; see Section 9.3, "Placing Users in Groups." You can also use Oracle Enterprise Pack for Eclipse to add a user to a group; see Section 4.3.1, "Adding a User to a Group with a JSP Tag."

If you are using an external user store, you should determine if there are existing groups in that user store and match those groups to the groups you are creating.

2.2.2 Using an Existing Group Structure

If the user store you are accessing already has users organized into groups, you can build a hierarchical tree in the Administration Console that matches the existing group structure. If you are using WebLogic Portal Server's default RDBMS user store, you do not need to build a group hierarchy tree. See Section 8.1.1, "Using a Group Hierarchy Tree" for instructions.

2.3 Working with a User Store

You can use the default RDBMS user store that comes with WebLogic Portal, or you can use a user store outside of WebLogic Portal. Examples of an external user store include OpenLDAP or Netscape's iPlanet. You can connect that provider to WebLogic Portal and the users in that external user store can log into your portal.

This section contains the following topics:

Section 2.3.1, "Editing User Information"
Section 2.3.2, "Accessing Multiple User Stores"
Section 2.3.3, "Planning to Use a UUP"
Section 2.3.4, "Using a Sample UUP Scenario"

2.3.1 Editing User Information

If you want to be able to edit information about your users, you must configure your external user store to allow write access. If the user store is writable, you can add users, groups, and user profiles that are stored in that user store. See theOracle Fusion Middleware Security Guide for Oracle WebLogic Portal for instructions on setting up external user stores and making them writable.

If the user store is read-only, the properties are visible in the portal but you cannot change them. The default configuration for supported external user stores is read-only access to users and groups from the Administration Console or the WebLogic Server Administration Console. The default RDBMS user store provides write access by default.

2.3.2 Accessing Multiple User Stores

If you have users stored in more than one external user store, you might want to access each of these user stores. WebLogic Portal supports using more than one authentication provider and more than one user store.

Accessing multiple user stores can help you perform the following portal administration tasks:

Let users in external user stores log into your portal desktops.
Provide personalized applications to users stored in an external user store. When those external users and groups appear in the Administration Console, you can define personalization rules based on the users and groups and their profile properties.
Entitle users in an external user store to specific portal resources when they log in. You can define visitor entitlement rules based on external users and groups.
Give users in an external user store administrative access to portal applications. You can define delegated administration roles based on external users and groups.

Tip:
Do not store identical user names or group names in more than one user store. If you are storing users, passwords, and groups in an external user store (such as OpenLDAP or Netscape's iPlanet), you can connect that user store to WebLogic Server (assuming it is a supported type), and the users in that external user store can log into your portals. For example, user dsmith can reside in the default RDBMS user store and in an external RDBMS user store. In this case, WebLogic Portal uses only one user profile for user dsmith.

After you follow the instructions in theOracle Fusion Middleware Security Guide for Oracle WebLogic Portal to develop and configure the external user store, the authentication provider for the user store appears in a drop-down list in the Administration Console. Two authentication providers appear in Figure 2-1.

Figure 2-1 Choose the Authentication Provider from the Drop-Down List

Description of "Figure 2-1 Choose the Authentication Provider from the Drop-Down List"

Note:

If your external user store contains additional properties for users and groups (for example, e-mail and phone numbers), accessing those properties involves separate development steps to create a UUP. See Chapter 6.

2.3.3 Planning to Use a UUP

Use UUP to retrieve additional user profile information from other user stores, such as OpenLDAP servers and databases, legacy applications, and flat files. Using a UUP to integrate existing systems with user profiles provides the following benefits:

Integrates with most other systems (because of the UUP open interface), so you can access existing user information without migrating that data into the portal schema.
Retrieves data from multiple systems and matches the data to one user profile type.
Uses multiple profile types in the same instance of a portal server.
Retrieves the same attribute from two different systems for two different users. For example, you can obtain a customer address property from SAP for Customer 1 and the same information from Oracle Financial for Customer 2.
Triggers personalization, sets role-based administration, and creates entitlements to limit access to portal resources.
You can create a UUP to retrieve additional user information stored in other external data stores.

Use a UUP to perform the following tasks:

Use WebLogic Portal's JSP tags, controls, or APIs to retrieve property values from that external user store.
View external properties in the Administration Console to define rules for personalization, delegated administration, or visitor entitlement. Users and groups are not considered properties.

You do not need to use an external data store's UUP to perform any of the following tasks:

Provide authentication for users in the external user store.
Define rules for personalization, delegated administration, or visitor entitlement based only on users or groups in an external user store, rather than on user properties.
Define rules for personalization, delegated administration, or visitor entitlement based on the user profile properties you create in Oracle Enterprise Pack for Eclipse, which are kept in the portal schema.

2.3.4 Using a Sample UUP Scenario

Use the following scenario to understand how and when to use a UUP:

You created a new portal application and you want users to be able to log into it.
Your users are stored in an RDBMS user store outside of the WebLogic Portal. You could connect WebLogic Server (your portal application's domain server instance) to your RDBMS system, and your users could log into your portal application as if their user names and passwords were stored in WebLogic Server. If authentication was all you wanted to provide through your RDBMS user store, you could stop here without using a UUP.
You also stored e-mail and phone number information (properties) for users in your RDBMS user store, and you want to access those properties in your portal applications. You must create a UUP for your RDBMS user store to access those additional properties from your code.

For instructions on how to set up a UUP, see Chapter 6.

2.4 Planning Data Encryption

WebLogic Portal provides two ways to encrypt your sensitive user profile data. You should choose the encryption method in the planning phase, before you begin the development phase. Both WebLogic Portal and WebLogic Server use the 3DES encryption algorithm.

Choose one of the following methods if you want to encrypt user data:

Enable encryption for your user profile property set – Select the Enable Encryption check box to have the Profile Manager encrypt all user profile data in the property set before you send it to the UUP. For more information, see Section 5.1, "Creating a User Profile."
Use your custom UUP adapter to perform your own encryption – If you plan to have your custom UUP encrypt the data for the property set you specify, do not select the Enable Encryption check box as described in Chapter 5. The Profile Manager sends and receives the data in clear text and encryption and decryption occur at the UUP. (If you do check the Enable Encryption check box, the data is encrypted and decrypted twice, and can impact performance. This type of double encryption is not recommended.)

Having the Profile Manager encrypt the data is the most secure method to encrypt data in WebLogic Portal. However, the Profile Manager manages encryption keys for each encrypted property set. If you want to share your encrypted data across portal applications or domains, you can transfer an encryption key from one custom UUP to another. For instructions, see Section 5.1.3, "Transferring an Encryption Key Between Custom UUPs."

This guide does not provide instructions on setting up encryption at your custom UUP. For information on why you would choose this method, see Section 2.4.3, "Encrypting Data by the Custom UUP."

2.4.1 Setting up a Password as an Encryption Key for Your UUP

Using a password as an encryption key to protect your UUP data is the easiest method to set up profile encryption for WebLogic Portal, but it is the least secure. You can use a clear text password or encrypt the password with weblogic.encrypt utility. For instructions on setting a password in the Administration Console, see Step 10 in Section A.2.1, "Configuring an LDAP UUP and Transparent Failover."

Note:

If you decide to use an encrypted password, your Database Administrator will not be able to view the data in the user profile database. In prior releases of WebLogic Portal, the default was clear text, which meant the Database Administrators could view the user profile data.

2.4.2 Enabling Encryption for a Property Set

When user profile data is retrieved from the UUP adapter, the data is decrypted on the fly. The encryption and decryption are transparent to the profile requester and the UUP. Encryption and decryption are performed at run time when set or get profile data is available through the Portal Administration Portal or profile APIs. Selecting the Enable Encryption check box generates an encryption key if you do not have a key assigned. The encryption key is written to the plan.xml file. If you have group profile data in the same encrypted property set as the user profile, the group profile data is also encrypted.

Select the Enable Encryption check box if any of the following scenarios apply:

You want the user profile data to be encrypted, but you do not want to develop your own encryption UUP
You do not want to send data over a UUP interface in clear text
You want to reuse an existing non-self-encryption UUP to enable encryption

To enable encryption for a property set, follow the instructions in Step 6 in Section 5.1.1, "Creating a User Profile Property Set."

2.4.3 Encrypting Data by the Custom UUP

An alternative encryption method is to set up encryption at your custom UUP. The Profile Manager sends the user profile data in clear text to the UUP and the UUP adapter encrypts the data and stores it. When the Profile Manager requests profile data, the UUP adapter decrypts the data to clear text and returns it in clear text. You do not need to perform additional configuration to your UUP adapter.

Tip:

Do not check the Enable Encryption check box (as described in Section 5.1.1, "Creating a User Profile Property Set"), because that option will encrypt and decrypt the data twice and can impact performance.

Enable encryption for a custom UUP if any of the following scenarios apply:

You already have a custom UUP adapter that encrypts data.
You prefer tight control of the encryption algorithm and data type verification, and prefer to encrypt the data yourself.

2.5 Upgrading Users and Groups from Portal 8.1

WebLogic Portal Server 9.2 contained a new default SQLAuthenticator authentication provider, which contains an RDBMS user store for users and group membership. The same default authentication provider is used currently.

When you run the Oracle WebLogic Upgrade Wizard, you can choose to upgrade your WebLogic Portal 8.1 SP4, SP5, or SP6, or Portal 9.2 or 9.2 MP1 users and groups or continue to use your existing RDBMS user store in Portal 8.1:

Upgrade users and groups – Choose to automatically upgrade your users and groups from WebLogic Portal 8.1 or 9.2 to the new RDBMS user store, which is part of the default SQLAuthenticator authentication provider in the WebLogic Portal 9.2 and the current installation. When you run the Oracle WebLogic Upgrade Wizard and it detects your Portal 8.1 RDBMSAuthenticator, you can select the Upgrade RDBMSAuthenticator option. Selecting this option replaces the existing authentication provider with the new SQLAuthenticator authentication provider and upgrades its contents, including users and groups.
Do not upgrade users and groups – Choose to continue to use the RDBMS user store from the default RDBMSAuthenticator in your WebLogic Portal 8.1 or 9.2 installation. When you run the Oracle WebLogic Upgrade Wizard and it detects your Portal 8.1 RDBMSAuthenticator, you can select the Do not upgrade RDBMSAuthenticator option. You can choose to manually upgrade your users and groups to the WLP 9.2 or current WLP RDBMS user store later. See the Oracle Fusion Middleware Upgrade Guide for Oracle WebLogic Portal for instructions.

For step-by-step upgrade instructions on running the Oracle WebLogic Upgrade Wizard, see the Oracle Fusion Middleware Upgrade Guide for Oracle WebLogic Portal.

2.6 Designing Users and Groups for Optimal Performance

Following are guidelines to follow when you create users and groups:

Plan and create your groups according to the roles you will create. If you do not consider roles in your group planning, you might have to redo your groups to accommodate roles.
Adjust your user management cache settings.