Symantec Access Management

Tech Tip : CA Single Sign-On : Review Active-Active CA SSO design

  • 1.  Tech Tip : CA Single Sign-On : Review Active-Active CA SSO design

    Posted 04-05-2019 05:36 AM

    Question:


    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 ?

     

    Answer:

     

    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/


    KB : KB000130537