You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

COmanage Registry Architecture Basics

COmanage Registry is a stateful PHP web application developed using the CakePHP 2.x framework. Currently the only web server supported is Apache HTTP Server (Apache) version 2.2 or 2.4.The application state is saved in a relational database. CakePHP 2.x supports several relational database server implementations.

Users authenticate to COmanage Registry using a federated identity. The Registry itself does not provide nor directly manage any particular federated identity authentication protocol but simply reads the Apache REMOTE_USER CGI environment variable for a user identifier. REMOTE_USER is expected to be populated using some federated identity technology. Common deployment patterns use the Shibboleth Native SP for Apache HTTP Server, SimpleSAMLphp, and mod_auth_openidc. Other user identifiers and user information may be consumed from other CGI environment variables.

After COmanage Registry authenticates a user by consuming REMOTE_USER the user identity is persisted across requests to the application using standard PHP session handling functionality. Specifically any session provided by the federated identity integration (eg. Shibboleth SP) is not required after the COmanage Registry PHP session is established.

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.

Common Deployment Pattern

Deployers commonly configure COmanage Registry to provision person and group records to a LDAP directory. Other services such as a SAML attribute authority (AA) or SAML proxy then use the LDAP directory as an authoritative source for user identifiers and attributes including group memberships, which are then often used for access control to services and applications. Some services directly query the LDAP directory for user or group memberships. Deployers also commonly configure COmanage Registry to provision group memberships to Grouper which in turn then provisions the group memberships to the LDAP directory or other systems.

The diagram below shows the common COmanage Registry deployment pattern.

COmanage Registry Common Deployment Architecture

High Availability Approaches

HA Only for Downstream Components

HA for COmanage Registry

  • No labels