17.7 Multi-Data Center Recommendations

This section contains recommendations regarding the Multi-Data Center functionality.

17.7.1 Using a Common Domain

It is recommended that WebGates be domain-scoped in a manner that a common domain can be inferred across all WebGates and the OAM Server Credential Collectors. This allows for WebGates to set an encrypted GITO cookie to be shared with the OAM Server.

For example, if WebGates are configured on applications.abc.com and the OAM Server Credential Collectors on server.abc.com, abc.com is the common domain used to set the GITO cookie. In scenarios where a common domain cannot be inferred, setting the GITO cookie is not practical as a given Data Center may not be aware of the latest user sessions in another Data Center. This would result in the Data Center computing session idle-timeout based on old session data and could result in re-authenticating the user even though a more active session lives elsewhere.

Note:

A similar issue occurs during server fail-over when the SessionContinuationOnSyncFailure property is set. The expectation is to retrieve the session from contents of the OAM_ID cookie. Since it's not possible to retrieve the actual inactivity time out value from the GITO cookie, a re-authentication could result.

When there is no common cookie domain across WebGates and OAM servers, make the following configuration changes to address idle time out issues.

  • Run the enableMultiDataCentreMode WLST command after removing the MDCGitoCookieDomain property from the input properties file.

  • Because a WebGate cookie cannot be refreshed during authorization, set the value of the WebGate cookie validity lower than the value of the session idle time out property. Consider a session idle time out value of 30 minutes and a WebGate cookie validity value of 15 minutes; in this case, every 15 minutes the session will be refreshed in the authenticating Data Center.

    Note:

    For 10G WebGates, since the token is not expired by the WebGate, the server will continue to honor a 10G WebGate cookie until the session in the base DC (authenticating DC) idles out.

17.7.2 Concerning the DCC and the OAM_GITO

The OAM_GITO cookie is not applicable when using the DCC.

Because of this:

  • The #MDCGitoCookieDomain= setting should be commented out.

  • The SessionMustBeAnchoredToDataCenterServicingUser parameter must be set to false.

  • The WebGate cookie expiration interval should be set as documented in Using a Common Domain

17.7.3 Using an External Load Balancer

Access Manager uses the 11g SDK API to retrieve session data but this API does not support SDK based load-balancing across the configured set of primary servers. Use an external TCP based load balancer to front-end the OAP endpoints of the Data Center nodes where high performance is expected.

Note:

Failover between primary and secondary OAM servers is supported in the current release of 11g SDK APIs.

17.7.4 Honoring Maximum Sessions

A typical Multi-Data Center scenario authenticates users against the Data Center with which the user geography has an affinity. In the rare scenarios where user authentication and session creation for a given user spans across member Data Centers (bypassing geographic affinity and load spike), the maximum sessions the user has in the whole Multi-Data Center topology would not be honored.

17.7.5 WebGate Cookie Cannot Be Refreshed During Authorization

Because a WebGate cookie cannot be refreshed during authorization, set the value of the WebGate cookie validity lower than the value of the session idle time out property.

Consider a session idle time out value of 30 minutes and a WebGate cookie validity value of 15 minutes; in this case, every 15 minutes the session will be refreshed in the authenticating Data Center. Setting the WebGate cookie expiration to less than 2 minutes is the recommendation.

Note:

This will not work for 10G WebGates because the 10G WebGate token expiration is driven by the server and not the WebGate. The server will continue to honor a 10G WebGate cookie until the session in the base DC (authenticating DC) idles out. A logout will work by clearing browser cookies; the dangling server side session will continue to exist but is considered harmless.