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@External Access Controlauthority.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 Pageor
Manager@Market News Pageroles. If you decide that you want to assign users to the
Editor@Market News Pagerole, which has not yet been externalized, follow these steps:
- 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.
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).