You are here

Revisit Account Management

Project ID: 
75
Current stage: 
Manager: 
Unit: 
What: 

Description: Rethink the way in which we perform account management, such that we can better manage multiple identities, and a large number of distributed services

Deliverables: A new account management system, comprising a central LDAP management directory, web interfaces to permit user managament of both roles and identities, propagation scripts for our current directories (LDAP, Kerberos, AFS). Copious documentation on how to add additional propagation scripts. Replacements for current account management tools such that the current command line behaviour is preserved.

Why: 

Customer: Ultimately, everyone with an account. Initially, those creating accounts and deploying services.

Case statement: As detailed in my "Account Musings" paper (produced at an earlier stage of this project), and November's development meeting talk (both of these are available from the above URL), the current account management system has a number of significant structural weaknesses. These weaknesses prevent it from easily adapting to emerging operational needs, such as management of fractured identities, and lightweight accounts, as well as preventing its simple integration with new services.

When: 

Status:

Timescales: Providing the project moves to implementation at December's meeting, and Simon's additional time gets contracted, a completed test service would be available by the end of March. The test service would then replace the current production account managemen

Priority: This project allows us to deliver significant user-facing functionality, in particular for the creation of keys for long running access to AFS.

Time: I'm stealing the "Time" field, as there doesn't seem to be anywhere to talk about external issues.

Both the current IDMS scoping exercise, and the IS plans for a central authorisation service impact upon this project. However, the timescales for progress on these appear far from clear, and unless they can be persuaded to adopt the model of "fractured identities", it's unlikely that either will meet our primary requirements. We're actively involved in talking to them about both, and it's envisaged that it will be possible to farm out portions of this system to the central authroisation service when it's development is complete.

In addition, the work being done on principal->identity mapping as part of this project will make it far easier to have DICE users with EASE principals.

How: 

Proposal: As detailed in the "Account Musings" paper, and refined at the November Development Meeting

Resources: The implementation will mainly be produced by Simon, but as noted above, there are components that would be better produced, and maintained, by members of other units. The availability of resources from those units will be critical to acheiving this.

Plan: The development will be undertaken in the following stages:

*) Design account management schema
*) Implement account management schema, authorisation model and LDAP directory
*) Implement overseer service to handle approval and warning events from syncronisation scripts
*) Implement syncronisation framework (initially in perl), but with design to allow use from other languages
*) Perform initial seeding of account management directory from current LDAP implementation
(This will involve writing an LDAP->LDAP syncronisation script, as a temporary tool, and as the first consumer of the syncronisation framework)
*) Bring up test infrastructure to trial new provisioning scripts against (test KDC, test AFS cell, test user LDAP directory)
*) Write Kerberos export syncronisation script
*) Write Account LDAP export syncronisation script
*) Write iFriend import syncronisation script
*) Write Divisional Database import syncronisation script (ideally done by someone with Database knowledge)
*) Write LCFG import syncronistation script (ideally done by someone from the MPU, this would replace the current lcfg2ldap tool)
*) Write AFS export syncronisation script (ideally written and maintained by someone from the Services Unit)
*) Build role management web frontend
*) Build identity management web frontend

Deployment will not take place until after the move into the new building. Before then, the new account management system will be run in development, taking a feed from our current system.

Other: 

Dependencies: Production of the database syncronisation script would ideally be done by someone with detailed knowledge of the Divisional Database
Production of the AFS syncronisation script would ideally be done by a member of the Services Unit
Production of the LCFG syncronisation script would ideally be done by a member of the MPU

Risks: If other units are to be involved in producing syncronisation scripts, the timely completion of these will be crucial to the project keeping to the timescales given above.

URL:http://www.dice.inf.ed.ac.uk/units/infrastructure/Documentation/Prometheus/

Milestones

Proposed date Achieved date Name Description
2007-09-24 2007-09-24 discussionPaper Discussion paper, as agreed at June meeting
2008-04-02 2008-01-01 milestones Create project milestones
2008-02-01 2008-04-02 architecture Design and document prometheus architecture
2008-03-21 2008-04-02 dependencies Package system dependencies
2008-03-21 2008-04-02 schema Design data model, and write schemas to create it
2008-03-28 2008-04-02 test system Install test system with all packages required for production.
2010-05-14 2010-05-14 role resolution Write code to evaluate role and entitlement relationships within the LDAP server
2010-05-14 2010-05-14 identity facets Write code to implement restrictions on identity entitlement and role ownership, based on role and entitlement tree and ownership model
2009-06-01 2009-06-30 Conduit API Define API for Conduit Prometheus communication, based on LDAP
2008-05-01 2008-05-16 Web Interface Create Web Interface permitting read only browsing of the prometheus tree
2009-08-01 2010-03-31 ldap conduit Write conduit to import current LDAP tree into prometheus
2010-03-31 2010-03-31 db conduit Write DB to prometheus conduit
2011-03-31 account life Implement account lifecycle
2010-06-17 2010-06-05 lcfg conduit Write LCFG to prometheus conduit
2010-11-20 2010-11-12 new server Install new server and put into operation (panther reverts to test server)
2010-08-10 2010-07-31 tools Write account management tools equivalent
2010-04-29 2010-04-16 ldap output Write LDAP output conduit
2010-03-31 2010-03-31 kdc conduit Write KDC output conduit
2010-08-15 2010-07-12 afs conduit Write AFS output conduits (pts and volumes)
2011-03-31 roles revamp Revamp of roles visibility and usage
2010-08-09 2010-08-31 refine framework refinements and bug fixes
2011-05-26 2011-03-31 documentation check API documentation accuracy/completeness
2010-03-31 2010-05-14 config finish configuration framework
2010-03-31 2010-05-14 error handling complete error handling framework
2010-04-03 2010-03-31 roles conduit Write roles import conduit
2010-05-30 2010-05-14 test server test prometheus ldap server running
2010-08-01 2010-06-21 plan roll-out Produce plan for roll-out
2010-04-30 2010-05-14 dummy services Dummy services being populated from prometheus
2011-04-30 2011-03-31 arbitrary entri Code for creation of arbitrary prometheus entries
2009-12-31 2009-12-31 framework complete core framework and API
2010-04-30 2010-06-30 commit web Commit web interface into code base
2010-07-19 2010-06-30 live populate Test servers populated from live upstream data using prometheus.
2011-07-20 2011-03-31 host ids Host identities code into service
2010-10-04 2010-09-30 overview-docs Write overview documentation aimed at computing staff
2011-09-01 2011-03-31 client-code Package client-side code and distribute everywhere
2010-11-26 2010-11-30 component Write component to manage prometheus server and configuration