ProjectIdentity

Overview

The identity service provides an abstracted, unified, modular approach to service provisioning. It allows services and account information to be manipulated as a user's identity changes. Students arrive or graduate, employees are hired, leave, or change jobs, people change their name, or any number of other situations occur in which a person's identity at the institution changes. This service consolidates the administration of identity management for an arbitrary set of provisioning systems (any system that contains a users account information or controls access to a service).

• identity v1.0.1 - identity is released under the GPL

If you download this software please let me know: cpepe at tearsoffire.

Because this framework is so generic it is not limited to service provisioning. While it is taylored to provisioning it can also effectively be used as a generic XML-RPC gateway into arbitrary systems. A connector can control any system so identity can read and write into any system and preserve a unified gateway over XML-RPC

Clients

Any system that can communicate via XML-RPC is capable of using the identity service. Some clients already exist to make manipulating accounts easier. More friendly clients are planned and will be documented here as they come online.

• xmlshell.py - Can be run anywhere that can talk to the identity server
• Web Interface - A separate service that offers an easy to use web front-end for the identity XML-RPC service

External Interface

The provisioning system is exposed through a XML-RPC interface. Information is brokered between the client to provision systems via the Provision Agent which includes a series of connectors that talk to the actual data stores to read or write data as requested by the client request.

XML-RPC API - Methods supported by the XML-RPC Server

ProvisionAgent

The core of the IDM is called the provision agent which consists of a provisioning manager and the provisioning systems (and their connectors to their data stores). The manager receives requests from the external interface and passes them off to the correct provisioning systems. Additionally, it attempts to catch any error that wasn't handled to keep the system running. The provisioning systems take the requests from the manager and process them through their connectors. Alone the agent does nothing, however, once the provisioning systems have loaded their connectors this platform offers a powerful, and simple way to manage services.

About the Provision Agent

Connectors

The data store can be literally anything that a computer can control (through python). The connector uses a standardized interface to hook into the provisioning system and is free to do whatever is needed to control the data store. Multiple connectors can talk to the same data store (ex. ConnADGrp could manage Active Directory Group membership, while ConnADUnix could manage Active Directory POSIX information for UNIX authentication) or a single connector can talk to multiple datastores (ex. The ZimbraConnector looks up user information in OpenLDAP and writes the information to the Zimbra LDAP server). The connector system makes it easier to isolate and simplify the provisioning task. New connectors should attempt to perform a single action to prevent the module from growing too large and difficult to maintain.

Connector Interface - Create custom connectors to integrate into the identity service

Connectors

• Zimbra
• Shell
• ActiveDirectory

Wisdom

Documentation

Installation

Requirements

• subversion (at least during initial development)
• python-ldap - LDAP library required for Zimbra Connector
• Unprivileged user identity (service runs as user identity)
  • User needs keys on Zimbra Store server to be able to ssh in and run zmprov
  • Be sure to ssh to the target server first using the FQDN and accept the key into known_hosts
    • Technically you need to use the hostname that is in the zimbra.conf file

Installation

• Check out lts-idm from subversion and copy
  • The init script expects the provisioning directory to be in /usr/lib/identity/
• Refer to simple_install.sh (running not advised, it is out of date)
  • the structure of identity has changed and the configs live in /etc/identity, the 'installer' is not updated for that piece
  • Copy provisioning to /usr/lib/identity
  • Diff existing config files with those in configs/etc/identity/, they should only differ by passwords if at all
• Edit config files in /etc/identity/conf/*
  • passwords.conf - contains the agent names and passwords used to authenticate to the xml-rpc server
  • server.conf - hostname, port, other standard config options
  • logging.conf - default logs to syslog
• Edit config files in /etc/identity/conf/connectors
  • Each connector must not have a config file to at least define the services it provides
• Set service to start on boot
  • chkconfig --add identity - the init script tells chkconfig how to add the service
• Allow Incoming connections Adjust the iptables rule to allow connections
  • -A RH-Firewall-1-INPUT -s x.x.x.x -m state --state NEW -m tcp -p tcp --dport 8000 -j ACCEPT

Upgrade from v1.0.0 to v1.0.1

This is done from memory as I haven't worked on this for a while. Retain a copy of all v1.0.0 files until it is clear that v1.0.1 is functional

• Stop the service /etc/init.d/identity stop
• Tag TRUNK as v1.0.1 and export v1.0.1 on idm-prod
• Copy provisioning to /usr/lib/identity/provisioning-v1.0.1
• Update symlink to /usr/lib/identity/provisioning to /usr/lib/identity/provisioning-v1.0.1
• I think everything else is unchanged. Double check the config files in /etc/identity/conf to be sure
• Start the service /etc/init.d/identity start
• Check /var/log/messages to ensure there are no errors

Configuration

Main Configuration Files

passwords.conf, server.conf, logging.conf

Connector Configuration Files

about connector config files...

Managing Connectors

Connectors can be installed at any point but the service will need to be restarted to load them. To install a connector copy/create a configuration file in /etc/identity/conf/connectors. Additionally copy the connector module to /usr/lib/identity/provisioning/connectors. It will be automatically loaded when the service is restarted. It is good practice to check syslog to ensure the connector loaded and is being used by identity. Any error in loading the connector will appear in syslog.

A connector can be disabled by renaming the module from myConnector to myConnector.disabled. Deleting the module will also remove the connector from service. Again the service must be restarted for the change to take effect. Disabling a connector but not restarting the service may cause problems if identity needs to access files in the connector and the path changes (due to renaming the connector).

Monitoring

nagios or other external monitoring as well as build in self tests to test connectors is planned but not actively being worked on.

XML-RPC Test

The XML-RPC server has a test method ok() that ensures the XML-RPC server is up and functioning. Some network events hose the input/output buffer and take the XML-RPC server down. The root cause and solution to this problem is unknown but sufficiently infrequent that it isn't being pursued.

Provisioning Agent Test

The test architecture is not presently in the provision agent but a scheduler has been incorporated to call periodic tests. The scheduler is part of the XML-RPC server and is expected to test the XML-RPC server as well as the connectors.

Issue Tracking

The reporting engine extends pythons logging class to include a failure level. A failure logs like a normal error as well as generates an error report and emails said report to a configured address. The reporting engine is configured in the main server.conf configuration file under [reporting].

Auditing