Administration Application Guide
|
 |
 |
|
|
 |
 |
This topic describes how to distribute configuration and policy data. The following topics are covered:
You must distribute both policy and configuration data before they can take effect. You can distribute policy data and configuration data together, or you can distribute only configuration data as structural changes. An application must be bound to an ASI Authorization and ASI Role Mapping provider before you can distribute a policy to the associated Security Service Module. Your policy data consists of the collection of rules that define your authorization policy.
When you distribute configuration data, you distribute the Security Service Module configurations to the Service Control Managers to which they are bound. Configuration data defines how the security providers are configured to protect your application. Configuration data defines the set of resources used by your provider configuration.
In the case of security configuration, you must select the Security Service Modules to receive the pending configuration. Results of all deployments for a session are displayed on the Distribution Results page. Structural changes (adding or removing bindings) are distributed automatically when either policy information or configuration information is distributed.
When you distribute policy or configuration changes, all structural changes are distributed together to maintain configuration and policy referential integrity within the system. If you make a change to a configuration, it is distributed the next time policy information is distributed. When you make a change to a policy binding, it is distributed the next time configuration information is distributed.
Distributing structural changes allows an administrator to provision changes to policy bindings and configuration bindings without distributing changes to policies or configurations themselves. In this way, a binding that is removed can be provisioned to the running Security Service Modules without having to distribute configuration or policy changes that may be waiting for distribution at another time.
After you design your policy, you must deploy it to the appropriate Security Service Modules before it can take effect. When you distribute policy data, you define the resources to be protected by that policy through the associated Security Service Module. An application must be bound to an Authorization and Role Mapping provider before you can distribute a policy to it; policy is not distributed to an application or resource.
The Policy tab displays a tree-like-structure of resources available to receive the policy. You define these resources as distribution points when you create them. If there is a "+" symbol for an item, you can expand that item to view its child nodes. Each resource item in the list has a check box.
Figure 11-1 shows a policy distribution with several resource nodes: WLES (with five child nodes) and WLESRecovery (with no child nodes).
Figure 11-1 Policy Distribution Results
The security policy is applied to the resource you select and is inherited by all resources below this distribution point (to all child nodes).
To distribute the Security Service Module configurations to the Service Control Managers to which they are bound:
The Configuration tab displays a tree-like-structure of Configurations, Providers, and Attributes that are available for policy distribution. If there is a "+" symbol beside an item, you can expand that item to view its child nodes. Each configuration, provider, and attribute item in the list has a check box.
Figure 11-2 shows a typical configuration distribution, representing a Security Service Module called myrealm that has six newly configured providers (ADDED). In the second Security Service Module configuration called wlesadmin, the ASI Adjudicator has been modified (UPDATED), and an Authorization provider (ASIAuthorizationProvider2) and Credential Mapping provider (DatabaseCredentialMapper) were added (ADDED).
Figure 11-2 Configuration Status
Structural changes (removal of bindings) are distributed automatically when either policy information or configuration information is distributed. When policy or configuration changes are distributed, all structural changes are distributed also to maintain configuration and policy referential integrity within the system.
Making a structural change to a configuration (unbinding a configuration from a Service Control Manager), means the change is distributed the next time policy information is distributed. Making a structural change to a policy binding (unbinding an application from an Authorization provider), makes the change the next time configuration information is distributed.
To distribute only structural changes:
Distributing structural changes only, allows an administrator to provision changes in policy bindings and configuration bindings without distributing changes to policies or configurations themselves. In this way, a binding that is removed can be provisioned to the running Security Service Modules without having to distribute configuration or policy changes that may be waiting for distribution at another time.
After you deploy your policy or configuration, you should verify that it was properly distributed.
To view the results of your deployment:
The Distribution Results page displays the results of any deployments done during your current working session.
Figure 11-3 shows the status of a distribution, showing the distribution ID, the username of the person who performed the distribution, the percentage of the distribution that completed, and the date and time of the distribution. The status report also indicates the components that received the policy, along with the group name and machine name (Host). The Instance represents the Service Control Manager and Authorization and Role Mapping provider that received the distribution.
Figure 11-3 Distribution Results
The Deployment Status page displays the name of each Service Control Manager and ARME instance registered with the Administration Application, indicating whether or not the policy or configuration data are synchronized with the database. When the configuration data for a Service Control Manager or policy data for the Security Service Module instance are not synchronized with the database, you may need to redeploy the data or refresh the instance to ensure that it is updated properly.
You can also use this page to remove any Security Service Module or Service Control Manager instance that you have uninstalled and is no longer in use.
To unregister and remove a Service Control Manager or ARME instance from the Administration Application:
The Deployment Status page displays the name of each Service Control Manager and ARME you have registered and deployed with the Administration Application. Figure 11-4 shows the status of a Service Control Manager (SCM) and ARME registered for use with the Administration Application. In this case, there is one Service Control Manager (SCM.asiconfig.wrko) and one ARME (WLES_admin_wlesadmin_wrko) instance.
Figure 11-4 Distribution Status
|
|
|
