|
|
This section describes ALES features that support recovery from failure. It contains the following topics:
In general, failover is the ability of a product to detect the failure of a particular component and switch to a working replica of that component without losing functionality. ALES support two failover scenarios:
ALES security providers depend on data stores for authentication, authorization, and credential mapping. You can configure ALES for failover in these important cases:
Note that SSMs have no runtime dependency on the Administration Server.
Failover for ALES administration functions can be achieved by installing a secondary, redundant Administration Server that will be used only when the primary becomes unavailable.
For example, consider the global deployment illustrated in Figure 3-2. The depicted enterprise has applications staged on servers in New York, Tokyo, and London. It has also deployed redundant ALES Administration Servers in its New York and London data centers and provides a replicated database to store ALES policies and entitlements information. Under normal conditions, administrators interact with the primary Administration Server in New York only. When policies are updated, the primary Administration Server pushes the changes to all SSMs in the global environment.
If the data center in New York goes down, as illustrated in Figure 3-3, the SSMs detect this failure and connect to the secondary Administration Server. The secondary Administration Server uses the primary database unless it becomes unavailable, in which case the server connects to the secondary database server (the replica).
Note that both the primary and secondary Administration Server can use either the primary or secondary database servers.
One benefit of the ALES architecture is that even if all Administration Servers, including secondary Administration Servers go down (for maintenance or due to failure), there is no impact on the applications in production or on the security services provided by the SSMs.
For information on how to configure the Administration Server for failover, see Setting up a Failover Administration Server.
Figure 3-3 provides a logical view of failover functionality when the primary database server fails.
Because the database server contains all the configuration and security data used by the Administration Application to protect applications and resources, it must be highly available and reliable. This can be accomplished by implementing the recommendations of the database manufacturer (for example, through the use of clustering architecture or hot standby).
The number of redundant database servers you configure can vary; however, a minimum of two is recommended to maintain reliable services. It is up to the system administrator to set up database failover and configure data replication between the database instances.
There are two approaches for making sure that two instances of the ALES database contain the same data:
Figure 3-4 illustrates the failover mechanism for the ALES Administration Server using Oracle RAC.
Common methods of achieving high availability include performing periodic back-ups, using fault tolerant disks, and manually copying files whenever they are changed. This is also the case for any optional external data sources in use. A database backup can be used for database recovery in the case of disk failure.
Use the Administration Console to configure failover support for database-related and LDAP authentication providers by specifying the secondary database or LDAP server, as described in the following sections.
A secondary database can be configured for Database Credential Mapping, Database Authentication, ASI Authorization, and ASI Role Mapper providers.
The ASI Authorization Provider contacts an external process to evaluate its authorization queries. If that process dies, the ASI Authorization provider denies access to all resources. This provider can be configured to contact the Administration database to retrieve subject attributes and group membership for use in authorization and delegation decisions. If the database connection fails, the provider connects to the configured secondary database and will also try to reconnect to the failed database after a configurable time-out. If all database connections fail and defined policies operate on user attributes and group membership, all access is denied.
A secondary LDAP server can be configured for Novell LDAP, Active Directory, iPlanet, and Open LDAP authenticators.
The NT Authenticator already supports multiple domain controllers. The WebLogic Authenticator, WebLogic Authorizer and WebLogic Role Mapper use WebLogic’s internal LDAP server as its data store. No support for a redundant source is required.
When a SCM starts, it contacts the Administration Server to obtain and cache the most current configuration data. When configuration data is modified, the Administration Server pushes the updates to the SCM.
Failover for the SCM server is implemented as follows:
SCM.properties file:
domain.asi.primary.pdurl — primary server addressdomain.asi.secondary.pdurl — secondary server address
| Note: | If a secondary server is not specified during installation, both properties will specify the primary server. |
The following tasks must be performed to set up a secondary Administration Server to provide failover support:
| Note: | For complete instructions on installing Administration Servers, see the Administration Server Installation Guide. |
The secondary Administration Server must installed on a separate machine and set up in the same manner as the primary Administration Server.
When complete, initialize the secondary trust stores as described in the next section.
When the secondary Administration Server is installed, a set of unique certificates is generated for it. Before starting the server, you must synchronize its trust stores with those in use on the primary Administration Server.
To initialize the secondary Administration Server trust stores:
ALES_HOME/primary-shared-keysALES_SHARED/keys directory from the primary Administration Server to the secondary Administration Server machine into the ALES_HOME/primary-shared-keys directory. /bin directory, execute initialize_backup_trust.bat|.sh. When prompted for the primary shared SSL directory, enter the path to the ALES_HOME/primary-shared-keys directory. When complete, enable trust synchronization as described in the next section.
Whenever a new SSM/SCM is enrolled — or an existing SSM/SCM is unenrolled — only the trust stores on the primary Administration Server are updated. Unless the secondary Administration Server’s trust store is also updated, problems may occur during failover, because the secondary Administration Server will not trust the new SSMs.
To insure that the trust stores on secondary Administration Server’s are current, the secondary server can be configured to perform periodic synchronization with the primary server’s trust stores.
| Note: | It is very important that the trust synchronization be enabled on the secondary Administration Server only. |
To configure the trust synchronization on the secondary Administration Server:
A sample completion of the Failover tab is shown in Figure 3-5.
|