Review Active-Active CA SSO design
Article ID: 130537
Updated On:
Products
CA Single Sign On Secure Proxy Server (SiteMinder)
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:
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/
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/
Feedback
Yes
No
Powered by
