...
COmanage Registry supports a REST interface. The REST client is authenticated via a simple user/password pair transmitted over HTTPS as part of a basic auth transaction. More sophisticated authentication mechanisms, such as delegated SAML assertions, may be supported in the future. No persistent session exists between WS calls or invocations.
...
Since many organizations only require HA for the services, tools, and applications that consume the information provisioned by COmanage Registry the most common HA approach is to focus on HA for access to LDAP directories and for some deployments Grouper web services (WS) (usually in a read-only mode for HA), and to not deploy COmanage Registry itself in a HA configuration. The diagram above depicts a common deployment scenario that includes a HA tier for LDAP replica servers and Grouper WS servers (and the HA database cluster on which Grouper WS depends). Services such as a SAML AA, SAML proxy, or clients that directly consume from LDAP are configured to rely on the set of LDAP replicas (which may or may not be served from a single logical service endpoint). In this scenario the COmanage Registry is not itself deployed in a HA configuration.
HA for COmanage Registry
When truly required or necessary, COmanage Registry can be deployed in a HA configuration using standard approaches:
- The relational database COmanage Registry uses to persist state must itself be deployed in a HA configuration.
- User PHP sessions must be consistent across the HA configuration (nodes) by either using session affinity (sticky sessions) or properly replicating sessions. Two commons approaches are to use Redis or memcached (not withstanding issues with memcached around its ability to recover from node failure). Writing sessions to a relational database that is itself configured for HA is also a common approach though for performance reasons it does not scale as well horizontally.
- Deployers must take into account any HA needs of the federated identity authentication protocol.