Staging with an external security manager (ESM)


Staging in scenarios where external security managers are used is complex and needs special consideration. This section discusses considerations of the impact of external security managers on the staging process.

External security managers can be used to externalize authentication and authorization decisions from the portal. Externalization of authentication decisions to an external security manager has no impact on the staging to production functionality. Management of authorizations by an external security manager has an impact on the staging to production scenario, this impact is discussed below. Using an external security manager for authorization decisions requires that the same external security manager is used to manage authentication to the portal.

Entities that are managed by a centralized security manager should only be manageable within that security manager. Managing those entities elsewhere violates the principles of centralized security control.

This principle does not change in staging-to-production support. For staging-to-production, this principle leads to the inability to modify security definitions of a resource that is externalized. The following sections describe the direct implications in external security manager (ESM) scenarios for staging-to-production.

The XML configuration interface is used for configuration management in the staging-to-production support. The XML configuration interface covers configurations that are managed by the portal. The XML configuration interface configuration files contain a list of all role mappings for all internally managed resources. Using external security managers allows management of entitlements for selected resources outside of the portal.

For WebSphere Portal 5.1, the XML configuration interface covers security definitions of externalized resources.

This new functionality for the XML configuration interface allows providing a request parameter within an export request; this parameter will cause the XML configuration interface to include role mappings of all resources within the XML configuration interface output file. The exported file contains role mappings for internally managed resources as well as externally managed resources. This allows for the staging of role mapping of all resources that are not already externalized in the target system.

The following support matrix illustrates staging support of entitlements in scenarios that involve external security managers (ESM). The source system refers to the system from which the configuration is exported (typically the integration system), and the target system is the system into which the configuration is going to be imported (e.g. staging or production system).

  no-ESM Target ESM Target
no-ESM Source All role mappings can be fully synchronized. Resources on the target system are initially managed internally after release staging. Resources can be externalized on the target system. Role mappings of externally managed resources in the target system are not synchronized (Warnings are generated during import).
ESM Source Role mappings of internalized resources can be synchronized. Synchronization of role mappings of externalized resources results in errors during import. (Manual configuration file updates ("change external to internal state") are required to prevent errors.) Role mappings of internalized resources are fully synchronized. Role mappings of externalized resources can be synchronized only on time of externalization. Role mappings for resources that are externalized on the target system cannot be synchronized.

In summary, role mappings can be synchronized as long as the resource is managed internally by the WebSphere Portal server. Once the resource is externalized, role mappings are owned by the ESM system and can not be synchronized. A special case is the time when a resource is externalized for the first time on the target system. In this case, it is possible to first modify the role mapping of this resource internally and then externalize the resource. During externalization, role mappings that were defined internally are recreated within the external security manager. Therefore it is possible to create new resources on the integration system, externalize the new resource to an ESM system, assign role mappings for it, and synchronize the new resources including role mappings to a target system. The resource together with all role mappings managed by the ESM system will be recreated on the target system.

However, it is not possible to modify role mappings for existing externalized resources and synchronize their updated role mappings to a target system.

 

Staging from system without ESM to a system with ESM

This combination is used where the integration system is reduced as much as possible and is configured like a development environment rather than a production environment.

All entitlements for all resources that are staged in this scenario are fully synchronized. All resources in the target system are managed internally. The external security manager is not used for managing authorization decisions.

It is possible to manually externalize resources. You can also manually edit XML configuration interface configuration files. In this step, all role mappings that were defined within the portal before are moved to the ESM. Managing these resources externally might include updating the role mappings of these resources outside the portal.

During staging of subsequent releases, resources with updated entitlements will appear in the XML configuration interface file as internally managed resources. These resources will be internalized at when this file is imported to the target system. Your can manually update the configurations for externally managed resources to prevent this. however, there is no build in support for managing these kinds of configurations. Special care must be taken to manually replicate all changes of role mappings of externalized resources on the target system.

 

Staging from system with ESM to system without ESM

It is unlikely that this scenario will be used by most customers.

In this scenario, entitlements for internalized resources can be staged without any limitations. These configurations appear as if the source system was not configured to use an ESM.

If entitlements for resources that are externalized on the source system are staged, errors will occur on the target system. During import of this configuration, the target system will be asked to externalize a resource, but the system is not configured to support resource externalization. This results in an error condition.

These errors can be resolved by manually updating the configuration file to have all resources managed internally. If role mappings for externalized resources are contained in the configuration file, entitlements will be synchronized between the two systems.

 

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.