Integrating external authorization systems

The WebSPhere POrtal server allows you to use a external security manager such as IBM's Tivoli Access Manager or Netegrity's siteminder for controlling authentication of portal resources. The Portal access control allows you to put individual subtrees of the protected resources hierarchy under external protection. For example using the resource permission portlet you can select a resource and change its externalization state. For example using Resource Permissions Portlet, you can select a resource and change its externalization state so that the resource and all resources in the subtree rooted at this resource are put under external access control. Inheritance always stops between resources that have different externalization state.

Portal server guarantees that each resource is either exclusively protected by portal access control or by the external system. Putting resources under external protection does not mean that the resource information as such is added to the protected object space of the external system. Only the roles that exist on those resources are registered there. An administrator of the external system can create role mappings for these roles, typically by assigning corresponding access control lists to the roles. The roles and role blocks are exclusively controlled by the portal. Only the mapping between roles and users/groups is managed through the external authorization system.

Ex. When you put the access control for Marketing Page under external access control then administer would be able to map users to role in the external access management system but what a role can do and the role block logic would still remain in the Portal

Changing the externalization status of resources is considered a sensitive operation and requires at least Security Administrator@Portal and Security Administrator@External Access Control authority.This resource is put under external protection during portal installation and cannot be internalized.

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, you must 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, you must 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, 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 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).