Staging and external security managers

External security managers (ESMs) are used to externalize authentication and authorization decisions from the portal. Role mappings can only be synchronized between portals using xmlaccess.sh if the resources are managed internally by portal. Role mappings for resources externalized to an ESM must share the same same ESM. We can set parameters within an xmlaccess.sh request to include role mappings in the export file for both internally managed and externally managed resources in the export file, allowing for the staging of role mapping of resources that are still managed by portal, and not already externalized in the target system. It is not possible to modify role mappings for existing externalized resources and synchronize their updated role mappings to a target system.

	Non-ESM target	ESM target
Non-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 reinternalized.
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 using xmlaccess.sh.

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 ESM is not used for managing authorization decisions. It is possible to manually externalize resources. We 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 appear in the XML configuration interface file as internally managed resources. These resources are internalized when this file is imported to the target system. We can manually update the configurations for externally managed resources to prevent this action. 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

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 occur on the target system. During import of this configuration, the target system is asked to externalize a resource. The system is not configured to support resource externalization. This option 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 are synchronized between the two systems.