User Management Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Adding and Managing Groups

After you use Planning a User and Group Strategy to determine your group structure, you can create, move, and delete a small number of groups in the WebLogic Portal Administration Console. Developers might prefer to do these same tasks for a large number of users in Workshop for WebLogic with JSP tags and controls.

You can also use groups to set up Delegated Administration and Visitor Entitlement; see the Administration Console. If the group exists before you add a user, you can then immediately add the user to the group.

Portal administrators with full group management rights can use the following tools to create and manage a small number of groups:

Developers can use the following tools to create and manage a large number of groups:

Tip: Users and groups are stored in the RDBMS user store server by default. The BEA Propagation Utility does not propagate this data from your staging environment to production.

The chapter includes the following sections:

 

Using Existing Groups

If the user store you are accessing already has users organized into groups, you can build a hierarchical tree in the Administration Console to organize and manage those existing groups. If you are using WebLogic server's default RDBMS user store, you do not need to build a group hierarchy tree.

This section contains the following topics:

Using a Group Hierarchy Tree

A tree view of groups provides a visual way to change group properties, find users in groups, and add users and groups to rules for Delegated Administration and Visitor Entitlement. Figure 8-1 shows a group hierarchy tree for the default SQLAuthenticator.

Figure 8-1 Group Hierarchy Tree

Group Hierarchy Tree

If you are connecting WebLogic Server to an external user store, your ability to see a hierarchy tree in the Administration Console depends on how the user store is supported. If the provider does not allow read access by external tools (such as the Administration Console), you will not be able to see the tree representation of the groups. See the Security Guide to determine if your user store allows read access. If the provider does not allow read access to its groups, you can still use the Administration Console to enter the names of known users and groups.

Building a Group Hierarchy Tree

Use the Authentication Hierarchy Service page to build and configure a group hierarchy tree for a read-access user store connected to WebLogic Server.

  1. Start the Administration Console.
  2. In the Administration Console, choose Configuration Settings > Service Administration.
  3. In the Resource Tree, select Security.
  4. In the Browse tab, click Authentication Hierarchy Service.
  5. Click Configuration Settings for: Authentication Hierarchy Service to display the provider’s settings, as shown in Figure 8-2.
    6. Figure 8-2 Retrieve Existing Groups by Building a Group Hierarchy Tree


    Retrieve Existing Groups by Building a Group Hierarchy Tree

  6. In the Description field, enter text that describes this group hierarchy tree. For example, iPlanetAuthenticator.
  7. In the Build Group Hierarchy Trees field, select one of the following choices:
    • Automatic – After the server starts or the application redeploys, group hierarchy trees are automatically built for the user stores listed in the Authentication Providers to Build list.
    • Manual – Group hierarchy trees for the user stores listed in the Authentication Providers to Build list are built when you click Update, letting you determine when the processing overhead for building the tree occurs.
      • Note: When you change the value of the Build Group Hierarchy Trees field, you must redeploy your enterprise application or restart the server.
  8. In the Sweep Interval field, specify how often the hierarchy trees are refreshed to show changes to users and groups. The Sweep Interval works with the Time to Live setting. The Sweep Interval determines how often (in seconds) the hierarchy trees are checked to see if they have expired (the time specified in the Time to Live field has ended). The default value is 300 seconds (five minutes).

    9. If a sweep finds the trees expired, the trees are cleared from memory and are not rebuilt until you try to access them in the Administration Console. Refreshing the trees more frequently can impact performance, but changes to users and groups are picked up more frequently.

    Tip: Set the Sweep Interval to the same value as Time to Live if you want the trees to be cleared from memory as soon as they expire. When you change this value, you must redeploy your enterprise application or restart the server.
  9. In the Maximum Number of Groups field, enter the highest possible number of groups that will be built and added to memory for all user stores.
  10. In the Time to Live field, enter how often the hierarchy trees should be refreshed to show changes to users and groups. The Time to Live field works with the Sweep Interval to determine how often (in seconds) the trees should be cleared from memory (expired).
    Set the Time to Live field to the same value as the Sweep Interval field if you want the trees to be cleared from memory as soon as they expire.
  11. In the Locale Language field, enter the two-digit language abbreviation (for example, en for English). The locale settings determine how the lists of users and groups are sorted. When you change this value, you must redeploy your enterprise application or restart the server.
    12. Tip: You can configure the default Locale Language in the netuix-config.xml file in the WEB-INF/ directory and also in the user’s preferred language setting in the browser. If the user's preferred language setting is empty, some browsers will automatically choose the default Locale Language on the client machine.
  12. In the Locale Country field, enter the two-letter country abbreviation. When you change this value, you must redeploy your enterprise application or restart the server.
  13. In the Locale Variant field, enter a vendor or browser-specific code. For example, use WIN for Windows, MAC for Macintosh, and POSIX for POSIX. Where there are two variants, separate them with an underscore, and put the most important one first. For example, a Traditional Spanish might use a locale with parameters for language, country and variant as: es, ES, Traditional_WIN. When you change this value, you must redeploy your enterprise application or restart the server.
  14. In the Available Authentication Providers field, select the user store, and click Add to build a hierarchy tree. User stores must allow read access before you can build a hierarchy tree.
  15. The Authentication Providers to Build field shows the user stores for which hierarchy trees are built. The Build Group Hierarchy Trees field described in step 7 determines when the trees are built.

    16. To remove a hierarchy tree for a user store in the Administration Console, select the name of the user store you want to remove, click Remove Selected, and click Update. The providers you can remove are listed in the Authentication Providers to Build field. After you remove the ability to build a hierarchy tree for a provider, you can still use a text entry field in the Administration Console to select users and groups for that provider.

  16. Click Update.
  17. Repeat these steps for each user store that has users and groups you want to see in the Administration Console.
  18. To view the group hierarchies for the user store, select Users, Groups, & Roles > Group Management. Select the user store you want to view in the drop-down box above the Group tree. You can also see the group hierarchy trees in the Groups in Role tab for a specific Delegated Administration or Visitor Entitlement role.
Tip: If a list of groups does not appear, verify that you built a group hierarchy tree for the user store. If you built the tree but you still do not see a list of groups, the user store probably does not allow read access. See the Security Guide for instructions on giving the provider read access.

 

Creating a Group or Subgroup

You can use the Administration Console to add a group during Staging. If you have a large number of groups to add, you can add them programmatically with JSP tags and controls during the Development phase. Typically, you will add just a few groups or make small changes to your group structure using the Administration Console during the Staging phase.

When you create a group, you are creating an empty group to which you can add an infinite number of users. You can also add a Group Profile, which contains additional information about a group.

Tip: Create groups before you add users to the Administration Console. If the group exists before you add a user, you can then immediately add the user to the group.

Perform the following steps to create a group in the Administration Console:

  1. In the Administration Console, choose Users, Groups, & Roles > Group Management.
  2. Select an authentication provider from the drop-down list above the group tree. If you are using an RDBMS user store, group names are case sensitive. A group called Managers is different than managers.
  3. Select Everyone to create a top-level group, or select a group in which you want to create a subgroup. If you do not see a list, verify that you built a group hierarchy tree as described in Building a Group Hierarchy Tree.
  4. Click Create Group.
  5. In the Create New Group dialog, enter the group name and description, and click Create Group as shown in Figure 8-3. The group name cannot contain special characters, such as \, <>, #, |, &, ~, ?, (), {}, %, or *.
    6. Figure 8-3 Create a New Top-Level Group


    Create a New Top-Level Group

Note: If you create a large number of groups, you can press PgDn to sort through the list of groups. Pagination improves performance by returning a smaller number of items.

If you add a subgroup to a group, the Remove From Group button appears. Clicking Remove From Group removes the subgroup’s membership from the parent group. The subgroup is not deleted from the system.

 

Editing a Group Profile

When you create a group, a Group Profile is automatically created for the group. A Group Profile contains 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. Group properties might include group manager, location, department, and so on.

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 by configuring a ProfileWrapper successor at runtime. A ProfileWrapper is a lightweight object that can access the correct ProfileManager session beans based on the profile identity with which it is initialized.

Perform the following steps in the Administration Console to edit the values in a group profile:

  1. In the Administration Console, choose Users, Groups, & Roles > Group Management.
  2. Select an authentication provider from the drop-down list above the Group tree.
  3. Select the group you want to edit. If you do not see a list of groups, you might need to build a group hierarchy tree for the user store. If you built a group hierarchy tree and still do not see a list of groups, the user store probably does not allow read access. See the Security Guide for instructions on providing access.
  4. Select the Group Profile tab.
  5. From the drop-down list, select the property set whose values you want to edit.
  6. Click Edit next to the property name to change the property’s value, as shown in Figure 8-4.
    7. Figure 8-4 Edit a Property’s Value


    Edit a Property’s Value

  7. After you enter the changes to the property’s value, click Update. If the properties belong to a read-only external property database, you cannot modify property values. Even though you cannot edit the properties themselves, you can still use these properties in setting up Personalization, Delegated Administration, and Visitor Entitlement. For information on Personalization, see the Interaction Management Guide. For information on Delegated Administration and Visitor Entitlement, see the Security Guide.
    8. Tip: If you delete the saved value, a successor value is returned if there is one defined. A successor value specifies the value to use if more than one value exists. If a user belongs to more than one group, you can choose which group properties to inherit. If you do not define a successor, the default value is returned. If there is no defined successor value or a default value, the property value is null.
  8. Repeat these steps to edit additional properties.

    9. If you cannot modify property values because they are read-only, the properties might originate from an external property database set up by your development team. You cannot edit the properties, but you can still use those properties to set up Personalization, Delegated Administration, and Visitor Entitlement.

You can determine which portal administrators can manage each user group by assigning Delegated Administration roles to those groups. See the Security Guide for instructions on assigning Delegated Administration.

Tip: 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).

 

Moving a Group

To change the hierarchy of your groups and subgroups, you can move an existing subgroup from one group to another or change it from a parent group to a child group.

WARNING: Moving a group can affect Delegated Administration and Visitor Entitlement roles. For example, if a group called Managers is used in a Delegated Administration role that grants full administrative access to the Administration Console, and you move a group under the Managers group, all users in that new subgroup will have full administrative access to the Administration Console. This is a convenient way to grant users Delegated Administration or Visitor Entitlement privileges.

If you are using an external user store for users and groups (one that is not the default RDBMS user store built into WebLogic Server), and you want to move a group in that user store, the provider may be configured to prevent moving a group from an outside tool (such as the WebLogic Portal Administration Console). If the Group Editor field for the user store is set to No, you cannot move a group in that provider with the Administration Console. You must move the group directly in that provider.

Perform the following steps to move a group in the group hierarchy:

  1. In the Administration Console, choose Users, Groups, & Roles > Group Management.
  2. Select an authentication provider from the drop-down list above the Group tree.
  3. In the Group tree, select the group you want to move. If you do not see a list of groups, verify that you built a group hierarchy tree for the user store. If you built the tree but you still do not see a list of groups, the user store probably does not allow read access. See the Security Guide for instructions on giving the provider read access.
  4. Right-click the group, and choose Move.
  5. Click OK on the dialog and then right-click the group where you want to place the new group, and choose Paste. You can also select Everyone to move the group to the top level.

 

Searching for a Group

If a user store contains thousands of groups, you might get better performance by not building a group hierarchy tree for the provider.

Perform the following steps to find a specific group if you did not build a group hierarchy tree:

  1. In the Administration Console, choose Users, Groups, & Roles > Group Management.
  2. Select the top-level group and then enter the name of the group you want to find in the Search for Groups section, as shown in Figure 8-5.
    3. Figure 8-5 Type the Group Name and Click Search to Retrieve It


    Type the Group Name and Click Search to Retrieve It

  3. Click Search. You can refine your search by selecting contains or ends with.

When you select a group this way, you can add and edit users and set up Delegated Administration for the group. However, without a group hierarchy tree, you cannot create, delete, or rearrange groups.

Note: You can disable all group hierarchy trees by adding the following code to the JAVA_OPTIONS line in your server startup script:
Note: -Dcom.bea.jsptools.disableGroupTree=true

 

Removing a Group

When you delete a group, you permanently remove the group and all of its subgroups from the user store. You must re-create all of the affected groups if you want to use them again. If you delete a group, the users that belong to the group are not deleted.

You can remove a subgroup from a group, and you can move a group within the group hierarchy to change its relationship to other groups. If the group was listed in a Delegated Administration or Visitor Entitlement role, you must also remove that group from the role definition.

You can delete a group in the Administration Console or if you use an external user store, you can remove the group there.

This section contains the following topics:

Removing a Group from an Internal User Store

Perform the following steps to delete a group:

  1. In the Administration Console, choose Users, Groups, & Roles > Group Management.
  2. Select an authentication provider from the drop-down list above the Resource Tree.
  3. Select the group you want to delete. If you do not see a list of groups, verify that you built a group hierarchy tree for the user store. If you built the tree but still do not see the groups, the user store probably does not allow read access. See the Security Guide for instructions on making the user store writable.
  4. Click Delete.
  5. If the group was listed in a Delegated Administration or Visitor Entitlement role, remove the group from the role definition on the Delegated Administration or Visitor Entitlement pages.

Removing a Group from an External User Store

If you are using an external user store to hold users and groups (one that is not the default RDBMS user store built into WebLogic Server), you can delete groups that were created in that provider.

If the external user store you are using does not support group deletion from an outside tool (the Group Remover field in WebLogic Server for the provider is set to No) you cannot delete a group for that provider with the Administration Console. You must delete the group directly in that provider.

Tip: If you are using an RDBMS user store, group names are case sensitive. For example, the Managers group is different than managers.

Perform the following steps to use the WebLogic Server Administration Console to remove a group from an external user store:

  1. To verify that your user store supports using an outside tool to remove groups, open the WebLogic Server Administration Console.
  2. In the left navigation pane, select Security Realms.
  3. Select your security realm.
  4. Select the Providers tab and then the Authentication tab.
  5. Select your user store.
  6. Select the Provider Specific tab and review the settings in the Group Remover field for the user store. If the Group Remover field appears and is set to Yes, you can use WebLogic Server or WebLogic Portal to remove groups in the user store. If you need to make the user store writable, follow the instructions in the Security Guide.
  7. In the WebLogic Server Administration Console, remove the group. Follow the instructions in Removing a Group from an Internal User Store.
Note: If you make changes to any user store configuration setting in the WebLogic Server Administration Console, restart the server. Restarting the server prevents exceptions in the WebLogic Portal Administration Console.

  Back to Top       Previous  Next