External authorization
WebSphere Portal always determines the permissions associated with each role, whether the role is externalized or not.
Roles are always associated with a specific resource. Resources can be moved back and forth from internal to external control with the Resource Permissions portlet. Explicit role assignments are preserved when moving in both directions. However, inherited role memberships are blocked for externalized resources. When we externalize access control for a resource, the resource is administered only through the external security manager interface. After externalizing the resource, 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 we 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 we 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 externalizing 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, use either the Resource Permissions portlet or the xmlaccess.sh to create additional role types on the resource. For example, suppose we created Administrator and Manager role types on the Market News Page. Then we externalize access control for the Market News Page. Use the external security manager to assign users to roles...
- Administrator@Market News Page
- Manager@Market News Page
To assign users to the Editor@Market News Page role, which is not yet externalized:
- Use the Resource Permissions portlet to create the Editor role type for the Market News Page.
- Use the external security manager to assign users to the Editor@Market News Page role by editing the ACL.
WebSphere Portal still determines the permissions associated with the externalized Editor role type.
If a user inherits access to a resource from a parent resource, the user loses the inherited access when the resource is externalized. If the user needs access to that resource, assign access through the external security manager.
The user, who externalizes the resource, 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 xmlaccess.sh).
The decision to use an external security manager must be made with the understanding the external security manager software's ACL semantics override WebSphere Portal semantics. For example, if we use Security Access Manager to grant anonymous membership on a role for an externally controlled portlet, set the ACL for that portlet to include the Security Access Manager unauthenticated user group.
If we use Security Access Manager for authorization, we must also use it for authentication. Using Security Access Manager to perform only authorization is not supported.