Architecture Guide
This architecture guide explains default assumptions about the system architecture for caGrid components that use authorization based on the CSM model. These are default configurations that should be modified appropriately to support increased performance or availability.
There are two basic configurations of system architecture that you should understand when planning to use authorization based on the CSM model. The simpler of the two is for a data service that serves data from a relational database.

This system architecture has two caGrid services and a database, all running on the same host. CSM authorization models are always stored in a relational database. Currently MySql and PostgreSQL databases are supported.
The service labeled “Data Service” is a caGrid data service that receives queries from its clients. It uses data in the database to supply the content of query results. It also uses the CSM authorization model in the same database to restrict which objects are considered by the query.
The service labeled “CSM Service” is a caGrid service that accesses just the CSM model in the database. The CSM service has two responsibilities:
- Together with the CSM UI, the CSM service is used to administer the information and configuration of the CSM authorization model.
- The CSM service's other responsibility is related to the administrative function of creating a user group definition in the CSM authorization model that is linked to a group defined by a gridGrouper Server. The CSM service is responsible for getting the definition for a linked group from the gridGrouper server. It is also responsible for keeping the definition of a linked user group in the CSM authorization model consistent with its definition in the gridGrouper server.
The CSM UI is the user interface that is used to administer authorizations. It runs within the GAARDS UI environment.
The other basic variation on the system architecture is a data service that gets it data from a data store that is not a relational database.

In this variation, the data service is getting its data from someplace other than the relational database that contains the authorization model. The other details of the system architecture remain the same.
In all cases, it is recommended that the relational database that contains the authorization model be on the same host as the two data services and that the database be inaccessible from outside the host. This is to make the authorization model more secure.





