External authorization

When portal resources are created, their access control is administered internally by WebSphere Portal. Alternately, you can configure an external security manager to control access to portal resources. Currently, WebSphere Portal supports Tivoli Access Manager and Netegrity SiteMinder as external security managers.

Beginning with WebSphere Portal V5.0, access control is role-based, and the externalization process has changed. Previous versions of WebSphere Portal worked with external security managers by externalizing resources and using ACLs to control permissions. WebSphere Portal now externalizes roles and uses ACLs to control role membership. From the perspective of the external security manager, these externalized roles contain only one permission: membership in the role.

WebSphere Portal always determines the permissions that the portal associates with each role. For example, if you externalize the Editor@Market News Page role, use the external security manager to edit the ACL for that role. WebSphere Portal still determines the permissions that are associated with the Editor role type. Roles are always associated with a specific portal resource, so the role Editor@Market news page contains specific permissions on the Market News Page only. For more information about role-based access control, see Authorization.

Roles on resources can be moved back and forth from internal to external control with the Resource Permissions portlet. When you externalize the roles for a resource, these roles are administered only through the external security manager interface. After roles are externalized, 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.

Note the following information:

  • 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 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, you 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, follow these steps:

    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.

  • 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.

 

See also

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

 

Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.