...
- A database query can return exactly one row. Then you can think of the row as a user object, and the column names become the properties of the object.
- A database query can return more than one row but only one column. Then you have a "multivalued" property for one user.
- An LDAP query returns the User object from the directory. LDAP User objects have properties some of which are single valued and some of which are multivalued.
Each column in the result set or property in the LDAP object becomes an Attribute of sorts, but this attribute has no SAML formatting information and no single identifier. To identify it you must both reference the id= of the DataConnector and the column or property name. To change that, you must use an AttributeDefinition.
Building a working pool of database connections is a complicated process. Shibboleth 2 generally relied on the application server (Tomcat or JBoss) capability to create and manage DataSource objects. Shibboleth 3 can also use datasources provided by the server, but it can also use datasources created by Spring support for databases. At this time we are sticking with Tomcat managed datasources, but we may move to Spring when we have a chance.
AttributeDefinitions
A query creates an attribute object for each database result set column or each property of the LDAP user object returned. These attribute objects are not directly useful because they are attached to the object created to represent the query result. You use them to create derived attribute objects that can stand on their own. To do this you configure an AttributeDefinition element with a sourceAttributeID that names the column/property and a Dependency that references the id of the query.
...