Business Continuity Planning (BCP) considerations for CA Single Sign On.

Products

• CA Single Sign On Secure Proxy Server (SiteMinder)
• CA Single Sign On SOA Security Manager (SiteMinder)
• CA Single Sign-On

Issue/Introduction

Description:

We have a server-farm consisting of 4 SSO servers: 2 servers on the first site and 2 servers on the second site. We plan to shutdown both SSO servers on the first site for 24 hours to simulate unavailability due to a disaster. It is expected that during this period of time various new user accounts will be created and application passwords will be changed.

What are the exact actions required to ensure SSO is remaining fully functional in this situation?

What implications there may be in respect of directory and data synchronization between the SSO servers on the first and second site?

Solution:

Whether or not your current configuration set is capable to sustain the planned outage is difficult to say given the vague numbers provided. However, provided that you are running with default settings for the SSO Servers there should not be any problem even in rather large environments.

Please note that there are several kind of data sets to be replicated:

Script data:

• By default TCL-script files are stored in the "scripts" folder of the SSO Server's installation location.
  
  
• There is no replication setup by default to farm peer systems, hence replication need to accomplished by other means, e.g. using OS' replication service, 3rd party replication or manual replication.

Access Control data:

• Is holding administrative users like ps-admin, application definitions and configuration settings.
  
  
• All transactions are queued in file system based objects (updates.dat), hence no data will be lost even after longer unavailability of the replication peers.
  
  
• Once the peer is coming back online all queued transactions are automatically fully flushed to them.

Directory data:

• In case of using ps-ldap as userDIR, it is holding SSO user accounts.
  
  
• Anyway it is holding user's application login credentials (LoginInfos)
  
  
• All transactions are queued using in-memory storage.
  
  
• By default SSO 8.1 is set multi-write-queue to hold 20000 transactions before overflowing.
  
  
• Once the peer is coming back online, all queued transactions are automatically fully flushed to them.
  
  
• Should the queue become overflowing, a manual synchronization of the directory can be done once the peers go back online.

Please see also these documents for further details:

• Multi-write FAQ: Sizing Multi-write Queues; Monitoring Multi-write Queues; Multi-write and Slow Links; Multi-write and Security
  
  
• How can I determine that multiwrite replication has failed?
  
  
• Can I stop a multi-write peer and resynchronize updates when it is bought back online?
  
  
• I need to recover a multi-write peer database that has been down for sometime. How do I re-sync it with it's multi-write peers?

Should you require specific sizing and configuration assistance, please do not hesitate to get in touch with your CA Account Manager to get CA Services team involved, since such tasks are going beyond CA Support scope.

Environment

Release:
Component: SMPLC