Seeing as I seem to have stalled in publishing the ‘vision’ documents I talked about earlier, here’s something more concerned with implementation nitty gritty: password handling.
In the wild, there appear to be three main approaches to handling passwords with an identity management system…
- Password syncronisation. In this model, the password field is just like any other attribute. A master copy is stored within the identity management system, and syncronised with each database it feeds. Changes are propagated using the standard attribute management mechanisms. This has the obvious security drawback that the account management system must hold a plaintext copy of every user’s passwords, and is therefore a pretty critical bit of infrastructure.
- Initial passwords. As its position on this list suggests, this is a half-way house. Instead of storing passwords for every user, the identity management system stores an ‘initial password’. This is used to populate the password field of a user when an entry is created in a subscribing database, but further changes are not mirrored in either direction. Any password syncronisation which occurs does so without the identity management system’s participation or knowledge
- No passwords. This model gives the account management system no knowledge of passwords at all. When new entries are created in subscribing databases, the syncronisation script is responsible for setting a password of its choice (typically a random one). All password management operations take place outside of the management system.
Each of these schemes has its drawbacks, and the intention is that prometheus will be capable of supporting all three.
And now, for the DICE specific bit. The issue for us here is one of workflow. Currently, an account isn’t “created” until a manual step is performed to take the account details out of the Divisional Database, and populate LDAP, Kerberos and the like. With prometheus, the account management system will be populated with all accounts that exist in the database, and the presence/absence of entitlements and roles will be all that stops them from being full blown accounts. Prometheus has to be able to handle the case where these entitlements appear automatically (perhaps even as a result of settings in the database). This means that there is no longer a human involved in the creation step, and so no way of setting a password, or even telling it which printer the password letter should come out of.
The solution to this will be to make the create account script be simply one which sets a password (it may also ensure the presence of various entitlements). In order to make this as portable as possible, we need to know for a given account where the password should be set – so there will be a prometheusPasswordStore field in LDAP, which contains a list of perl modules implementing Prometheus::PasswordStore which should be called with the users password when its changed through this script.
Similar technology could be used to maintain initial passwords when using the 2nd model. When the 1st model is in use, the password need only be updated within the prometheus LDAP store – however, this means we need to ensure that the frontends have code for managing password fields, even if our local implementation doesn’t use them.
Posted by sxw