Review Active-Active CA SSO design

book

Article ID: 130537

calendar_today

Updated On:

Products

CA Single Sign On Secure Proxy Server (SiteMinder) AXIOMATICS POLICY SERVER CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On

Issue/Introduction



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 ? 

Environment

Release: MSPSSO99000-12.8-Single Sign-On-for Business Users-MSP
Component:

Resolution

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. 

  https://docops.ca.com/ca-single-sign-on/12-7/en/implementing/implementing-ca-single-sign-on/architectural-use-cases 

On the other hand, our Documentation about configuring the Oracle
Database driver for failover allows writes to more than 1 Session
Store.

  Configure the Oracle Wire Protocol Driver for Oracle RAC without SCAN 

  AlternateServers= 

  If the primary server is not accepting connections, specifies the 
  connection failover to the other Oracle nodes. 

  Example: 
  (HostName=nete_servername2:PortNumber=1521:ServiceName=nete_servicename[,...]) 

  LoadBalancing=1 

  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. 

  https://docops.ca.com/ca-single-sign-on/12-7/en/installing/install-a-policy-server/configure-odbc-databases-as-policy-session-key-and-audit-stores/configure-odbc-databases-as-session-store/store-session-information-in-oracle 

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/