www.flickr.com
tres frijoles' photos More of tres frijoles' photos
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script -->
You are here: tearsoffire.org > Projects Web > SoftwareDevelopment > ProjectIdentity > IdentityConnectorInterface r1 - 24 Mar 2009 - 19:51 - ChristopherPepe


Start of topic | Skip to actions

Connector Interface

A connector is an abstraction of the end provisioning system (i.e. OpenLDAP). The connector knows how to communicate with the end provisioning system which allows the Provision Manager to control the data flow into and out of the end system. This allows the Manager to only handle provision requests while knowing nothing about the actual data stores that it is interacting with.

A base connector object handles the lowest level logic to simplify connector design. Connectors should inherit from the Connector object provided in systems, and must initialize by passing a unique name to the Connector initialization method upon instantiation. That mouthful means be sure to call Connector.__init__(self, name='ConnectorNameHere') within the custom connectors init method as shown in the example below.

Each method is optional and if a method is not implemented in the connector the Provision Manager will handle exceptions that are raised. An example of where this is useful is in interfacing with another departments data store. Our department can read their data but cannot change it; the connector really only needs get_account_info and the other methods, which write data into the end system, can be ignored.

Provision System Request (PSR)

Each method in the connector takes a psr as the only input. The psr object is defined in systems as a ProvisionRequest. This object wraps up all of the data that is passed into the Provision Manager to allow the connectors to process the requested data.

ALERT! The workflow of this systems has changed considerably and the ProvisionRequest object is likely to change in future releases to better match the needs of the system.

Provision Request Attributes
action The type of request being made: provisioning, info, update
id The unique tracking ID assigned to this request for audit trail
services The services the request is to act upon: email, shell, test
uid Unique ID of the user that is recognized by the end provision system
allow Boolean to enable or disable the user's account; maybe be deprecated
data Dictionary containing the connector names as keys and a payload**

** The payload is request specific but is generally a dictionary of attributes:values to be updated. A provision request is given to a specific connector in one of two ways. First the service attribute of the psr matches a service provided by the connector. Second, the data attribute of the psr has a key that is the name of the connector. Thus to request info from connectors 'ConnA' and 'ConnB' the easiest way is to set psr.data to {'ConnA':1, 'ConnB':1}. The values are ignored so they can be set to anything.

bg_init

The purpose of the background initialization is to perform any task that may take a long time. By moving the task to inside of the connector thread long pauses do not effect other systems loading or the service in general. bg_init should update the connectors status attribute (see systems.py) to properly reflect its state.

Arguments: PSR, uid is used
Returns: 2 value tuple: True/False, initialization message (errors, all's well...)

enable_account

This method should enable the proper user's account. This may involve first creating an account or just adding the users name to the proper file. As always it is system specific.

Arguments: PSR, uid is used
Returns: True/False

disable_account

This method should disable the proper user's account. This may involve deleting the account, hiding the account, or just locking the account from use. As always it is system specific.

Arguments: PSR, uid is used
Returns: True/False

get_account_info

This method should return whatever information should be exposed about the user. If the requested user does not have an account in the system then the account status value should be systems.NO_ACCOUNT Roles are not supported so information either is or is not exposed to any client using the identity service. Consider the following example:

Attributes in SomeDataStore for user 'cpepe' are: uid:cpepe, job:programmer, password:myPasswordIsAwesome, phone:781-555-5634

Passwords are sensitive data and generally aren't going to be passed around, especially if they are stored in clear text. get_account_info may only return the uid, job, and phone attributes while omitting the password. It is up to the connector to expose information to the identity service.

Arguments: psr, Nothing is used
Returns: Dictionary of attributes and their current values

NEW status should be set to systems.ENABLED, systems.DISABLED, systems.NO_ACCOUNT, or another value in the account states section of systems.py

update_account

This method should use the input psr to update a users account information. As with get_account_info the connector has as much flexibility as it needs. Continuing with the example of SomeDataStore; the uid attribute is used as the key for the account and cannot be changed in most cases. Logic in this method can create readonly attributes to prevent them from being changed (assuming the end provisioning system would allow them to be changed).

Arguments: PSR, Data contains a dictionary of attributes and values to be updated
Returns: True/False

Example Connector

This is a fully functional and legitimate connector for use with the identity service. The enable and disable methods do nothing but do report success back to the Provision Manager. Enable/disable actions will be recorded as successful in the audit trail. The account information is created on the fly and complete nonsense however it could just as easily have been read from a database, flatfile, remote system, or any other data source. Similarly the update method merely prints out the input given to it but could use that information in any way that is relevant to the provision system it is connecting to.


"""
Test Connector to allow nop and test actions to query a running IDM server.

@author cpepe@brandeis.edu
@date   14 July 2008
"""
import os
import time
import systems
from systems import Connector

class TestConnector(Connector):
    def __init__(self):
        Connector.__init__(self, name='TestConnector',
            configFile='/etc/identity/conf/connectors/test.conf')
    
    def bg_init(self):    
        self.status = systems.LOADED
        return True, 'Test connector loaded'
    
    def enable_account(self, psr):
        return True
    
    def disable_account(self, psr):
        return True
    
    def get_account_info(self, psr):
        """
        dummy up some information about the user that is 'stored' in the test connector
        """
        import os
        import random
        return { psr.uid : {'uid': psr.uid, 'status': systems.ENABLED, 'random': random.randint(0,100)} }
    
    def update_account(self, psr):
        if type(psr.data) is not type(dict()):
            logger.error('%s: [PSR %s] Account cannot be updated because data is in invalid format: %s' % (self.name, str(psr.id), str(psr.data)))
            return False                                  #<-- Early Return
        for key, val in psr.data.iteritems():
            print '%s: Pretending to update %s with %s' % (self.name, str(key), str(val))
        return True
    


Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r1 | More topic actions
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding tearsoffire.org? Send feedback