Provision Agent

Introduction

The Provision Agent acts as the broker between the client and end provision system. The agent provides a modular, abstract interface which allows the client and end provision system to know nothing about each other. Additional end provision systems can be added to the agent at any time, be seamlessly integrated into the agent, and be available for use by clients.

Client Interfaces

XML-RPC

XML-RPC was chosen as the initial interface to the Provision Agent. The XML-RPC interface and XML-RPC server are not a part of the Provision Agent, rather a means to expose the Provision Agent to the client.

Provision Manager

The Provision Manager is a top level aggregator to allow the client a single entity to control all of the end provisioning systems. The manager inspects the incoming provision requests and interrogates the registered Provision Systems to ascertain of the request is relevant for the provision system. If so the manager adds the request to that provision systems request queue. Additionally the manager will collect and roll-up responses from the Provision Systems to create a concise response for the client.

Provision System

The Provision system is the top level abstraction of the actual provisioning system. It provides the common functionality that all provision systems need to have but that is unimportant to the actual end provisioning system. It houses the actual connector as well as managing the information flow between the manager and connector via the incoming request queue and outgoing response tracker (auditing system). The Provision System also maintains information about what the connector is capable of doing, namely what services it is responsible for and how the connection to the end provisioning system should be handled.

Provision Requests that are placed in the Provision System's queue by the manager are handled sequentially by the Provision System. The result of the request is stored in the auditing system to provide feedback to the client and provide an additional audit trail to logging.

Connector

The connector provides the interface between the Provision System and the actual provisioning system. This is the lowest level abstraction and the most likely piece of code for developers and administrators to interact with. The connector runs within a thread in the Provision System so that long operations in the connector do not slow down the overall service. The purpose of the connector is to pass information to and from the provisioning system and the Provision System. In the case of OpenLDAP the connector would know how to look up the attributes associated with a particular DN and pass that information, probably as a dictionary, back to the Provision System Object. Additionally the connector would know the proper LDAP commands to update a DN based on the dictionary of attribute:value pairs passed to it. The power of the identity service is in the connectors. A system can be made read-only by not implementing code in the connector that writes to the provisioning system. Only certain attributes could be exposed to protect sensitive information (like password or SSN). Finally, the connector allows identity to use virtually anything as a datastore. So long as the connector code can read and or write to the datastore it can be used (OpenLDAP or a coffee maker, as long as a computer can control it).

Connectors should inherit from the Connector object in systems. This provides most of the framework needed by a connector to interact with the Provision Agent. See the example connector for how to best utilize this master object.

-- ChristopherPepe - 28 Aug 2008