Dev Meeting Prometheus Lifecycle September 2014

Brief history

Devproj page

All details

Managing the lifecycle of a user's accounts was always part of our plan for prometheus, but it was pushed back as deadlines approached. A number of designs were considered before one was settled on. Some code was written, but was lost in a combined disk/backup failure. We took this design, wrote some code, and this is what we'll be using.

The current situation

With a few exceptions, roles and entitlements are what tell our systems what a user can and can't do.

We get this roles/entitlements data from a couple of places. Upstream roles come from the school database and grant users the entitlements to have a DICE account - a KDC entry, AFS PTS and VLDB entries and an LDAP record. When a user loses their right to an account, they lose these entitlements.

Or sometimes what happens is that the user will disappear from prometheus's view of the database entirely. This is worse.

And of course, we also manually manage additional (or secondary) roles and entitlements for users.

Why this is horrible

In the context of account lifecycle, this situation is unpleasant because we have no reliable way of knowing when a user's account has ended. This means that we don't know when a grace period should start and end.

Also, we have no way of accurately knowing when we can delete an account.

We can get end dates from the database, but not for all users and they're not always reliable.

Our lack of a grace period means that roles and entitlements are lost as soon as they are lost upstream, so users may find that although their account is still active, they can't do much with it.

Manually added roles and entitlements are different, of course - they don't disappear and so they will persist until they are manually dealt with.

And people who have disappeared from the database view leave their prometheus records as they were before they disappeared - a state of limbo.

This is all a bit horrible.

How lifecycle works (in brief)

So, lifecycle seeks to address these shortcomings...

The University defines different grace periods for different account categories - here. We intend to broadly follow these, with a few adjustments.

The grace periods will be defined through a special entitlement, in the same roles rfe map that the account-granting ones are defined.

The lifecycle code will kick in once a user has lost the account-granting entitlement from upstream.

In essence, what it does is fairly simple - when a user's account ends, lifecycle preserves the entitlements that they've lost for the duration of their grace period (with a few exceptions).

One decision we made was that lifecycle code will also explicitly remove any manually added roles/entitlements from the user's prometheus object (but these will be preserved for the user's grace period).

Changes to roles/entitlements

For all of this to work, we need to add a bit of complexity to the way entitlements are defined in roles rfe maps.

Firstly, prometheus/grace:X (where X is a number of days) is the special entitlement for applying a grace period to a user.

For other entitlements, we add some prefix characters to give them meaning for lifecycle...


Preserved entitlements are the default case and will be preserved for the user's grace period.

Fixed entitlements are preserved until they are manually removed.

No-grace entitlements are not preserved for any grace period.

Negated entitlements will remove an entitlement from a user. These have been around for a long time, but I don't think ever used.

An rfe readme file will be provided summarising all of this.

Changes to prometheus

These changes mean that a user's entity record in prometheus needs to maintain a certain amount of state - that is, not just what it is now, but what it was before, so this involves tracking the various types of entitlements. Fixed and preserved entitlements are collectively known as "protected" entitlements.

Prometheus's Role Expander conduit builds a full list of entitlements for each user. In the case of a user who is in their grace period, this now means adding any protected entitlements which may have been lost back to the list.

Account and grace end dates will also be maintained.

As prometheus's store is LDAP, this allows us to easily query and modify the data. For example, setting a different expiry date for one entitlement, or setting the expiry date for all of a user's entitlements to 'today'.

There's a tool, called prometheus-lifecycle, to assist with these kinds of things. As well as one-off changes, it will be used to produce daily summary reports.


This has been running on a test server, with real data, for quite some time now.

We plan to put it into service once the current period of database flux has ended. It seemed unwise to implement a system so heavily dependent on roles from the database at the same time as those roles themselves are undergoing significant transition.

-- TobyBlake - 15 Sep 2014

This topic: DICE > PrometheusLifecycleDevUpdate201409
Topic revision: r1 - 15 Sep 2014 - 10:22:59 - TobyBlake
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 TWiki? Send feedback
This Wiki uses Cookies