The following sections contain information on how the Multi-Data Center deals with session time outs and syncs.
Credential Collector user affinity ensures that maximum session constraints per user are honored.
There is no Multi-Data Center session store to validate allowed maximum sessions per user.
The OAM_ID and OAM_GITO cookies are used to calculate and enforce idle (inactivity) timeouts. The OAM_GITO cookie, though, can be set only if there is a common sub-domain across WebGates. Thus, Multi-Data Center policies should be configured based on whether or not the OAM_GITO cookie is set.
Table 17-1 documents the policy configurations.
Table 17-1 Multi-Data Center Policy Configurations for Idle Timeout
| OAM_GITO Set | Multi-Data Center Policies |
|---|---|
|
Yes Idle timeout will be calculated from the latest OAM_GITO cookie |
SessionMustBeAnchoredToDataCenterServicingUser=<true/false> SessionDataRetrievalOnDemand=true Reauthenticate=false SessionDataRetrievalOnDemandMax_retry_attempts=<number> SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds> SessionContinuationOnSyncFailure=<true/false> MDCGitoCookieDomain=<sub domain> |
|
No Idle time out will be calculated from the OAM_ID cookie because OAM_GITO is not available |
SessionMustBeAnchoredToDataCenterServicingUser=false SessionDataRetrievalOnDemand=true Reauthenticate=false SessionDataRetrievalOnDemandMax_retry_attempts=<number> SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds> SessionContinuationOnSyncFailure=<true/false> #MDCGitoCookieDomain= This setting should be commented or removed |
Session expiration will be managed by the Data Center with which the user has affinity.
Users have affinity to a particular Data Center based on the global traffic manager/load balancer.
When a valid session corresponding to the user's request exists in a remote data center, based on MDC session synchronization policies, the remote session attributes are migrated and synced to the data center servicing the current request. If the synchronization fails, the datacenter can still access the requested resource as the Webgate failover across data centers is supported by the MDC.
Access Manager server side sessions are created and maintained based on single sign-on (SSO) credentials. The attributes stored in the session include (but are not limited to) the user identifier, an identity store reference, subject, custom attributes, partner data, client IP address and authentication level. SSO will be granted if the server can locate a valid session corresponding to the user's request.
In a Multi-Data Center scenario, when a user request hops across Data Centers, the Data Center servicing the request should validate for a legitimate session locally and across Data Centers. If a valid session for a given request exists in a remote Data Center, the remote session needs to be migrated to the current Data Center based on the MDC session synchronization policies. (See Multi-Data Center Deployments.) During this session synchronization, all session attributes from the remote session are synced to the newly created session in the Data Center servicing the current request.
The Multi-Data Center also supports WebGate failover across Data Centers. When a WebGate fails over from one Data Center to a second, the session data can not be synchronized because the first Data Center servers are down. Thus, the second Data Center will decide whether or not to proceed with the session adoption based on the setting configured for SessionContinuationOnSyncFailure. When true, even if the OAP communication to the remote Data Center fails, the Data Center servicing the current request can proceed to create a new session locally based on the mandatory attributes available in the cookie. This provides seamless access to the requested resource despite the synchronization failure. Table 17-2 summarizes prominent session synchronization and failover scenarios. The parameters in this table are explained in greater detail in Table 18-4.
Table 17-2 Session Synchronization and Failover Scenarios
| MDC Deployment | MDC Policy | Validate Remote Session | Session Synchronized in DC Servicing User From Remote DC | Terminate Remote Session | User Challenged |
|---|---|---|---|---|---|
|
Active-Active |
SessionMustBeAnchoredToDataCenterServicingUser=true SessionDataRetrievalOnDemand=true Reauthenticate=false SessionDataRetrievalOnDemandMax_retry_attempts=<number> SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds> SessionContinuationOnSyncFailure= false MDCGitoCookieDomain=<sub domain> |
Yes |
Yes |
Yes |
When a valid session could not be located in a remote DC |
|
Active-Active |
SessionMustBeAnchoredToDataCenterServicingUser=false SessionDataRetrievalOnDemand=true Reauthenticate=false SessionDataRetrievalOnDemandMax_retry_attempts=<number> SessionDataRetrievalOnDemandMax_conn_wait_time=<millisecon ds> SessionContinuationOnSyncFailure= false MDCGitoCookieDomain=<sub domain> |
Yes |
Yes |
No |
When a valid session could not be located in a remote DC |
|
Active-Standby |
SessionMustBeAnchoredToDataCenterServicingUser=true SessionDataRetrievalOnDemand=true Reauthenticate=false SessionDataRetrievalOnDemandMax_retry_attempts=<number> SessionDataRetrievalOnDemandMax_conn_wait_time=<millisecon ds> SessionContinuationOnSyncFailure= false MDCGitoCookieDomain=<sub domain> |
Could not validate as the remote DC is down |
No, since the remote DC is down |
Could not terminate as the remote DC is down |
Yes |
|
Active-Standby |
SessionMustBeAnchoredToDataCenterServicingUser=true SessionDataRetrievalOnDemand=true Reauthenticate=false SessionDataRetrievalOnDemandMax_retry_attempts=<number> SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds> SessionContinuationOnSyncFailure= true MDCGitoCookieDomain=<sub domain> |
Could not validate as the remote DC is down |
No, since the remote DC is down |
Could not terminate as the remote DC is down |
No Provides seamless access by creating a local session from the details available in the valid cookie |