Skip to end of metadata
Go to start of metadata

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.

  • No labels