You are here
Revisit Account Management
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.
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.
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.
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.
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 |