Unified Connector Framework
|
OUTDATED
This page is outdated, it contains information that was not updated in a long time.
The described functionality may or may not work.
Do not rely on information provided on this page.
|
Goal
Keep creating simple connector simple. The connectors should be required to implement only few mandatory operations. All the rest should be optional with the ability of the framework to simulate some of the "advanced" operations. This allows building of really smart connectors and provisioning system can take advantage of them.
Drawbacks
The provisioning system might be quite complex, as there are many options that connector can choose.
Functional Requirements
-
Basic operation
-
Provide configuration schema
-
Provide resource schema (mandatory!)
-
Suggest human-readable object class names optional
-
localized names optional
-
-
Mark attribute limitations (read-only, write-only, …) optional
-
Suggest human-readable attribute names optional
-
localized names optional
-
-
-
List connector capabilities optional
-
Validate configuration (without applying it) optional
-
Check connection to resource optional
-
-
Resource Objects
-
Read resource object
-
Create resource object
-
Modify resource object
-
relative changes (add, delete values) optional
-
absolute changes (replace values)
-
-
Delete resource object
-
list object containers optional
-
list resource objects by object class and container
-
iterative (blocks)
-
paging support optional
-
-
return number of objects by object class and container optional
-
search resource objects using flexible search criteria optional
-
iterative (blocks)
-
paging support optional
-
-
-
Account objects optional
-
disable account
-
enable account
-
suggest object classes for accounts (in the schema)
-
-
Credentials
-
reset password
-
enforce password change on next login (or generic "credentials" change)
-
-
Entitlements optional
-
list entitlement types (in the schema)
-
assign entitlements to account
-
-
Real-time change detection optional
-
"CreatedOrModified" change type - absolute state
-
"Created" change type optional
-
"Modified" change type - relative changes optional
-
"Deleted" change type optional
Non-Functional Requirements
Connector should try to execute all actions atomically
Q: What actions must be atomic?
Support for asynchronous operations
Mechanics
The interface should not be modeled as simple synchronous request-response with each operation called individually. The operations should be passed to the interface in sets, due to the following reasons:
-
Atomicity. Some connectors may be able to execute the whole set atomically. This gives us more reliable error recovery.
-
Asynchronous operation.
Represent Resource schema in a form compatible with (representable as) XML Schema (XSD).
Represent objects in a form compatible with (representable as) XML infoset.
Use URIs for namespace separation compatible with XML namespaces.