...
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.
...
This behaviour is very similar to the current LDAP provisioner in CoManage.
Supported attributes
The following attributes are supported:
| friendly name | OID |
|---|---|
| eduPersonAffiliation | 1.3.6.1.4.1.5923.1.1.1.1 |
| eduPersonEntitlement | 1.3.6.1.4.1.5923.1.1.1.7 |
| eduPersonPrincipalName | 1.3.6.1.4.1.5923.1.1.1.6 |
| eduPersonScopedAffiliation | 1.3.6.1.4.1.5923.1.1.1.9 |
| eduPersonUniqueId | 1.3.6.1.4.1.5923.1.1.1.13 |
| eduPersonOrcid | 1.3.6.1.4.1.5923.1.1.1.16 |
| cn | 2.5.4.3 |
| description | 2.5.4.13 |
| displayName | 2.16.840.1.113730.3.1.241 |
| facsimileTelephoneNumber | 2.5.4.23 |
| givenName | 2.5.4.42 |
| l | 2.5.4.7 |
| labeledURI | 1.3.6.1.4.1.250.1.57 |
| 0.9.2342.19200300.100.1.3 | |
| mobile | 0.9.2342.19200300.100.1.41 |
| o | 2.5.4.10 |
| ou | 2.5.4.11 |
| postalAddress | 2.5.4.16 |
| postalCode | 2.5.4.17 |
| sn | 2.5.4.4 |
| st | 2.5.4.8 |
| street | 2.5.4.9 |
| telephoneNumber | 2.5.4.20 |
| title | 2.5.4.12 |
| uid | 0.9.2342.19200300.100.1.1 |
| isMemberOf | 1.3.6.1.4.1.5923.1.5.1.1 |
MySQL AA data model
Because we cannot beforehand know how many attribute values we need to store for a given user (multiple emails, group memberships, entitlements) we will store the AA data in a flat table that mimics a key value store.
Comanage supports eduPerson out of the box so most attributes can be mapped directly form the CoManage data model to