Highlevel setup

For the basic service we want to have a rather simple attribute model to be exposed by the VOpaas AA. The AA of the basis service should only rely on providing attributes that exist in well known schema. If a VO needs custom attributes, they should be using the advanced services.

COmanage standardizes on eduPerson Schema, but also allows arbitrary attributes to be configured to express roles and rights within the VO. In addition Comanage allows groups and group memberships to be defined.

For scalability we want Comanage to be decoupled from the AAs, so we can scale the AA separately (see technical design). We will use a MySQL database in master-slave mode to achieve this. The master database will be connected to CoManage, whereas the slaves (1-n) will be on the VMs that provide the AA capabilities. To avoid possible issue with the MySQL data model of the Comanage application, we will decouple the data model from CoManage from the data model we will use for the AAs. In addition this allows us to tune and tweak these databases specifically for their tasks (read/write vs write once, read many). To transfer teh data from the CoManage database to the AA database we will use a standard feature of Comanage called the provisioning plugins. A provisioning plugin may be defined for a VO to deliver in real time changes to the data that is being managed via CoManage into a so called "provisioning target". We will define the same plugin for all VOs, which will provision data to the AA database which lives on the Master MySQL database, which will act as our provisioning target. The mysql master-slave mechanism will then peculate the changes towards the slave nodes.

Mapping attributes between CoManage and AA db

Mapping attributes from the Comanage schema to the AA schema will be done by the CoManage SQL provisioner plugin. This plugin will contain the business logic to perform the right mappings.

Given that Comanage already supports eduPERSON schema, it seems logical to use a one on one mapping of these attributes in the AA database schema. Only consideration to take into account is that several attributes may actually be multi valued, also we will not support all attributes in eduPerson, as some are rarely used, and others come with data protection constraints.

For the custom attributes that may be defined in Comanage to define roles and rights, as well as for groups a different approach is needed:

• roles and rights will be mapped all  attributes into an eduPersonEntitlement attribute, for which the values will be scoped to the VO and will follow a described semantic setup.
• all groups will be expressed as IsMemeberOf attribute values, again scoped to the VO

This behaviour is very similar to the current LDAP provisioner.

The following attributes are supported:

Comanage supports eduPerson out of the box so most attributes can be mapped directly form the CoManage data model to