External authorization

 

+

Search Tips   |   Advanced Search

 

When portal resources are created, their access control is administered internally by WebSphere Portal.

Alternately, we can configure an external security manager to control access to portal resources. Currently, WebSphere Portal supports...

  • IBM Tivoli Access Manager for e-business
  • Computer Associates eTrust SiteMinder

...as external security managers.

WebSphere Portal always determines the permissions that the portal associates with each role, whether the role is externalized or not. Roles are always associated with a specific portal resource.

Resources can be moved back and forth from internal to external control with the Resource Permissions portlet in WebSphere Portal. Explicit role assignments are preserved when moving in both directions. However, inherited role memberships are blocked for externalized resources.

When you externalize access control for a resource, the resource is administered only through the external security manager interface. After externalization, role membership must be assigned and removed using the external security manager. The Resource Permissions portlet can no longer control user access to the resource; however, the Resource Permissions portlet can move the object back to internal control.

  • Private pages cannot be externalized.

  • When you use the Resource Permissions portlet to externalize or internalize access control for a resource, access control for all of its public child resources moves with it. When you use the XML configuration interface (xmlaccess) to externalize or internalize access control for a resource, access control for public child resources does not change.

  • After you externalize access control for a resource, use the external security manager to assign users to roles on the resource.

  • After access control for a resource is externalized, we can use either the Resource Permissions portlet or the XML configuration interface to create additional role types on the resource. For example, suppose you create only the Administrator and Manager role types on the Market News Page. Then you externalize access control for the Market News Page. At this point, use the external security manager to assign users to the Administrator@Market News Page or Manager@Market News Page roles. If you decide that you want to assign users to the Editor@Market News Page role, which has not yet been externalized...

    1. Use the Resource Permissions portlet to create the Editor role type for the Market News Page.

    2. Use the external security manager to assign users to the Editor@Market News Page role by editing the ACL.

    Remember that WebSphere Portal will still determine the permissions that are associated with the externalized Editor role type.

  • Externalizing the access control for a resource severs any access control inheritance from internally controlled parent resources. The user who is performing the externalization automatically receives the Administrator role on the parent resource of the externalized resource tree (if using the Resource Permissions portlet) or the resource (if using the XML configuration interface).

The decision to use an external security manager must be made with the understanding that the external security manager software's ACL semantics override WebSphere Portal semantics. For example, if you use Tivoli Access Manager to grant anonymous membership on a role for an externally controlled portlet, set the ACL for that portlet to include the Tivoli Access Manager unauthenticated user group.

 

Example: Assign resource permissions for profiling

Set resource permissions for profiling and personalization.

  1. Set page and portlet permissions for the group Tutorial_Groups...

    • Log on to WebSphere Portal as an administrator such as wpsadmin.

    • Using Resource Permissions, grant User access on the root content page to the Tutorial_Groups group.

    • Using Resource Permissions, grant Privileged User access for the portlets...

      • Tutorial - Profiling - Working Version
      • Solution Version

      ...to the Tutorial_Groups group.

  2. Test the edit page controls as a test user.

    • Switch over to WebSphere Portal and start a new session by logging out.

    • Log in as one of the test users.

      Do not log in as a user who is a member of the wps_admins group. Users in this group have a different impact on the behaviors of the personalization page.

    • Open to the page containing the portlet for this tutorial.

    • Click the drop-down arrow in the upper right corner of the portlet and choose Personalize to open the Edit page.

    • Make various choices about which columns to display, whether or not to group detail data, etc.,

    • Click OK and see what impact those choices have on the behavior of the portlet.

      Be careful not to tell the portlet to sort on a column that does not exist. For example, if you choose to hide all optional columns and use SortSortAction2, there will be only two sortable columns but you will have told the portlet to perform its initial sort on the third sortable column. Since there is no third sortable column, you will get an error in the portlet.

  3. Test the edit page controls as a different test user.

    • Log out and log in as a different test user.

    • Click the drop-down arrow in the upper right corner of the portlet and choose Personalize to open the personalization page.

    • Make some choices here that are noticeably different than the choices you made for the first user.

    • Click OK to save those changes and to see the impact they have on the portlet.

  4. Switch back to the first user and test again

    • Log out and log in as the first user.

    • Note that the preferences you made for the first user are still applied in spite of having made changes on the personalization page for the second user. The fact that these preferences remain is proof that the personalization features of the personalization page are working.

 

Related information

 

Parent Topic

External security managers