CA Single Sign On Secure Proxy Server (SiteMinder)AXIOMATICS POLICY SERVERCA Single Sign On SOA Security Manager (SiteMinder)CA Single Sign-On
Does the Policy Server supports loadbalancing between 2 instances of ODBC Session Stores, which means that it can write to both ODBC Session Stores ? Or should it be configured to write only to 1 ODBC Session Store instance in failover scenario ?
Release: MSPSSO99000-12.8-Single Sign-On-for Business Users-MSP Component:
On one hand, our Documentation precises that Policy Server should write to the same database, and several ODBC instances of Session Stores can be replicated.
Policy Server to Session Store Communication
If you deploy a session store, all Policy Servers in the environment must use the same session store database.
Deploying a master session store is a way to achieve session store redundancy. A master session store lets each Policy Server communicate with the closest replicated version.
>>> the diagram shows a direct link from Chicago Policy Server to >>> Chicago Session Store replica, not to the Master. The Boston >>> Policy Server goes to the Boston Replica.
Turns on client load balancing, which helps to distribute new connections to keep RAC nodes from being overwhelmed with connection requests. When enabled, the order in which primary and alternate database servers are accessed is random.
So said, Policy Server does support the fail over configuration between multiple instances of ODBC Session Stores, which can be configured from SiteMinder Management console.
Please note that replication should be configured between the multiple instances of ODBC Session Stores to achieve Single Sign-On in case of fail over.
Load Balancing with multiple instances of ODBC Session Stores are not tested internally with in the Database Source Name (DSN).
If you deploy a session store, we recommend to have all Policy Servers in the environment to use the same session store database.
To configure Session Store high availability, follow one of the ways listed that suits the organization requirement.
A centralized replicated session store to enable single sign–on between all applications as documented at https://docops.ca.com/ca-single-sign-on/12-8/en/implementing/implementing-ca-single-sign-on/multiple-data-centers/
A master session store lets each Policy Server communicate with the closest replicated version as documented at https://docops.ca.com/ca-single-sign-on/12-8/en/implementing/implementing-ca-single-sign-on/architectural-use-cases/