Data Flow
LDAPPC provisions objects to targets. Objects consist of identifiers, attributes, and references to other objects. Provisioned objects are calculated from source data processed by the Shibboleth Attribute Resolver.
The Shibboleth Attribute Resolver accepts many DataConnectors (sources), including LDAP, RDBMS, and Grouper. Custom DataConnectors may be provided.
LDAPPC provisions targets using a standardized provisioning language, SPML. An SPML to LDAP connector is provided. Provisioning non-LDAP targets requires a target specific connector, for example, SPML to RDBMS.
SPML
LDAPPC has been rewritten to include an (incomplete) SPML 2 provider and LDAP target.
"An SPML provider is a software component that requests, listens for, processes, and returns the results of provisioning requests.
An SPML target represents an endpoint that a provider makes available for provisioning actions."
LDAPPC provisions objects consisting of an identifier, attributes, and references (to object identifiers), which are computed by the Shibboleth Attribute Resolver. LDAPPC considers group memberships to be references.
Currently, LDAPPC supports SPML requests represented as Java objects as provided by the Oasis implementation. The SPML requestor will be Grouper's CLI, gsh, and the target implementation will be LDAP. A future iteration should be able to send and receive SPML via web services.
Requests and Responses
The Provisioning Service Provider implementation class, PSP.java, accepts and returns SPML requests, which are similar to LDAP directory operations : add, delete, modify, lookup, and search.
Most SPML requests consist of an object identifier, target identifier, and "return data". The return data is either "identifier", "data" (identifier+attributes), or "everything" (identifier+attributes+references).
LDAPPC defines custom requests : calc, diff, sync, bulkcalc, bulkdiff, and bulksync.
Most Responses consist of a status code ("success" or "failure") and representations of provisioned objects.
calc
Upon receipt of a CalcRequest, the PSP will calculate how an object (or objects) should be provisioned via the Attribute Resolver, and will return the provisioning represented as a CalcResponse.
diff
Upon receipt of a DiffRequest, the PSP first performs a CalcRequest in order to determine how objects should be provisioned. Then, the PSP queries each target to determine how objects are provisioned. The PSP returns a DiffResponse representing the changes necessary to synchronize the provisioned objects. The changes consist of AddRequests, DeleteRequests, or ModifyRequests.
sync
Upon receipt of a SyncRequest, the PSP first performs a DiffRequest to determine provisioning changes. Then, the PSP requests targets to perform the changes, and returns the results as a SyncResponse.
bulk*
Bulk requests operate on all groups, and are similar to the pre-NG style of operation.
Custom Extensions
LDAPPC's configuration is modeled upon Shibboleth's use of Spring, which will allow deployers to customize targets as well as the identifiers, attributes, and references returned from the Attribute Resolver.
To provision a target other than LDAP, an implementation class must be able to handle add, delete, modify, lookup, and search requests.
The supplied LDAP target essentially maps SPML to LDAP operations.
Configuration Example
The following is an example of how a group might be provisioned.
The ref attribute of <identifier>, <attribute>, and <reference> elements refers to the id of an attribute as defined in the Attribute Resolver configuration. If the ref attribute is not specified, it defaults to the value of the name attribute.
<object id="group" ... >
<identifier ref="groupDn" baseId="ou=groups,dc=grouper,dc=edu" />
<attribute name="objectClass" />
<attribute name="cn" />
<references name="member" >
<reference ref="members" toObject="group" />
</references>
</object
The corresponding Attribute Resolver configuration will contain :
<resolver:AttributeDefinition id="cn" xsi:type="ad:Simple" sourceAttributeID="name"> <resolver:Dependency ref="GroupDataConnector" /> </resolver:AttributeDefinition> <resolver:DataConnector id="GroupDataConnector" xsi:type="grouper:GroupDataConnector" />
Incremental Provisioning Theory
TODO
Questions or comments? 
Contact us.