Roles and Capabilities

The following are observations that may be helpful in deciding the current and future state and management of the roles and capabilities namespace (which relate to the Review roles mechanism Project)

Overview

Refresher definitions:

  • role: the name given to a collection of capabilities (or entitlements in the Prometheus world)
  • primary roles (or upstream roles in Prometheus): a grouping of capabilities derived from the School DB (generated internally from other data)
  • secondary roles (or additional roles in Prometheus): a grouping of capabilities derived from Prometheus (assigned/generated manually)
  • capabilities (entitlements): a free-form string used to denote a particular usage or function (and a capability/entitlement only exists when used - it cannot exist other than in a role definition or directly applied to a Prometheus entity

Note that capabilities have no enforced syntax, although many of them currently follow the form:

  • service/access, or
  • service/service-specific-tag/access, or
  • service/service-specific-tag

also:

  • group/GROUP
(which assigns membership to Unix group GROUP)

and:

  • prometheus/TRIGGER

which is an internal, administrative Prometheus trigger for account provisioning (for example, prometheus/afsHomeDirectory enables the creation of the users home directory).

(Note that it is up to whatever checks the capabilities/entitlements to make sense of the name.)

All roles are instantiated by a correspondingly-named rfe map (which defines what capabilities or entitlements that role has), but membership can only be assigned by the School DB (in which case the role is regarded as primary) or via Prometheus (in which case the role is regarded as secondary). The School DB generates the primary role names, but does not actually create the roles - the rfe map needs to be manually created and edited for both secondary and primary roles (and these maps may, therefore, not necessarily exist).

Roles are imported from the School DB and from rfe maps into Prometheus, which then generates its own LDAP structure. This data is then exported to System LDAP, and it is this information source that is queried for role and capability details by applications and other interested parties (there is a slight delay between updating Prometheus LDAP and System LDAP).

We currently have around 1350 roles, but only around 680 capabilities (which includes the 485 "group/*" capabilities that trigger group membership).

Primary roles are assigned to accounts from within the School DB (and thus the role is "populated", although this information is not explicit in the database - there is no "roles" table, with role and membership fields). Primary roles fall into six broad categories:

  • classes
  • modules
  • years
  • degrees
  • staff (including visitors)
  • course duties (<duty>-<module|class>)

...where a category may contain only a few high-level roles ("staff", "ex-staff", or "new-staff"), or multiple sub-category roles such as:

Role Definition Number
class-
[DEFUNCT]
A student will have a class-<CLASS> role for each class that they are a member of. 63
module- A student will be assigned a module-<MODULE> role for each course (formerly module) that they are a member of (whether or not that module role actually exists) .
(There may also be <MODULE>-<string> roles for per-module tutorial, practical, or other grouping.)
385
year- A student will have a year-<YEAR> role for each year that they are a member of. 20
degree- A student will have a degree-<DEGREE> role for the degree programme of study that they are following. 58
old-degree- A student will have an old-degree-<DEGREE> role for any degree that they were but are no longer studying. 70
new-degree- A student will have a new-degree-<DEGREE> role for any degree programme of study that is about to be started. 44

- with course duties such as:

demonstrator- A user will have a demonstrator-<MODULE> role for each module for which they are a demonstrator 31
tutor- A user will have a tutor-<MODULE> role for each module for which they are a tutor 35
ta- A user will have a ta-<MODULE> role for each module for which they are a teaching assistant 27

...which totals approximately 740 roles, leaving around 610 ad-hoc roles.

So what's the problem?

There are too many roles. They lack coherence, they are not always created, and are not usually deleted when no longer needed. Because of a lack of co-ordination, the use of roles has become inconsistent and, often, misleading.

We need to take a closer look at what we want to use roles for, and how they're managed - the structure and organisation of roles does, to an extent, reflect our organisational policy and therefore has a wider significance. Although changes to methods of management may help us to make things work more effectively in the future, it is the namespace containing the actual roles and entitlements (capabilities) that is the current problem (although this over-population is not actually breaking anything, but it is perpetuating confusion and inconsistency).

The overheads for primary roles are minimal (management could probably be automated, and the roles left to their own devices), but the overheads for secondary roles are greater, and care should be taken not to create secondary roles without good reason (and to make sure that they don't outlive their usefulness).

Observations and Proposals

The move to Prometheus introduced the active-person and inactive-person roles - the former containing the entitlements to confer accounts, and currently given to staff, new-staff, tempvisitor, degree-*, and new-degree-* roles.

  • The "class-*" roles are now defunct, they should be removed.

  • The name of a role should be descriptive and relevant, but should not be relied on to provide a hook for ad-hoc searches. Any definitive searches should be done using data management tools, since the relevant information repository (InfDB or Prometheus) defines role membership (even though it does not instantiate the role).

  • Role/capability/entitlement names should have a standard format (insofar as such a thing is possible). This would (hopefully) make the identification of roles with similar/duplicate functions easier (although implementing this for existing roles and entitlements as well as new ones would be rather involved).

Note that it was agreed "during an August 2011 meeting that all units should be responsible for the roles/entitlements provision for the services which they provide", so:

  • the management of the roles namespace should be divided along Unit lines

What we can do now, and what we might do later

There are two separate and distinct tasks that are relevant to this project: a general tidy-up of the roles namespace, and a re-organisation of that namespace and relevant management tools and mechanisms.

Tidy up existing roles

It should be possible to examine all roles and capabilities to make sure that there are no redundancies or naming inconsistencies - but this would have to be a manual inspection process.

  • any secondary roles that are not in use by users or by other roles should be deleted

Roles which have had their rfe maps removed might continue to exist in the database but - pending an automatic creation and deletion mechanism - the namespace should be kept as sparse as possible to cut down on administrative overhead (there may well be a computational overhead too). Note that there is an action on Toby and Graham to investigate the automatic creation (and deletion) of rfe maps for roles assigned by the database which, by definition, concerns primary roles only (see https://wiki.inf.ed.ac.uk/DICE/PrometheusInfDB20120515, but this is - as yet - unscheduled).

NOTE that the benefits of unused role deletion may not be that great - and who's to say that a currently-unused role or entitlement may not be needed in the future?

We should also:

  • sort out the over-inclusion of the @person role - this is currently included in too many inappropriate places.

  • include end dates in Prometheus when secondary roles are assigned to users, so that they will be removed in a timely fashion. (Although desirable, the implementation of this is not trivial to implement)

  • add end dates to role definitions, where appropriate. Note that this is different to adding end dates to role assignments, and that the method of adding end dates will be different for primary and secondary roles, because of the different repository types. (Adding end dates to role definitions is easier to do than adding end dates to user assignments, and thus may be practicable.)

  • identify and delete unused secondary roles (identified via Prometheus, and then manually checked to confirm redundancy) [not implemented]

  • make sure that module roles only contain module-specific information (this is related to the current misuse of the @person role)

Functional categories

As part of automatic account creation, some roles are used to trigger the account creation process (by possession of the active-person role), and these are currently:

  • staff
  • new-staff
  • tempvisitor
  • degree-<DEGREE>
  • new-degree-<DEGREE>

...but not everyone with the degree-<DEGREE> role actually needs an account (those with degree-ext role, for example).

To reduce the number of unwanted accounts, the account-creation triggers - currently defined in the @active-person role:

 
    % rfe -g roles/active-person
    # Role for an active person, i.e. someone who needs accounts on DICE
    # systems

    @person

    # entitlement which will lead to prometheus creating an identity
    prometheus/localIdentity

    # entitlement to trigger creation of an AFS home dir
    prometheus/afsHomeDirectory

    # entitlement to trigger creation of AFS pts entry
    prometheus/afsUser

    # entitlement to trigger creation of system ldap (rfc 2307) entry for
    # user under ou=People
    prometheus/ldapPerson
    % 

could appear in all module roles where an account is required , as well as in all degree roles except the degree-ext role. The account-creation triggers cannot exist only in the module roles because these are assigned after the student has matriculated and needs his or her account (in fact, a particular module role may not even have a corresponding rfe map). NOTE that this would contravene the proposed rule that module roles only contain module-specific information.

Alternatively, a new account role be created - something like a new 'full-account-holder' role - thus divorcing the account-creating triggers from the person roles (thus removing the need for the @active-person and @inactive-person roles). This would involve adding this new role to the five categories of account creation trigger roles mentioned above, and removing the @active-person and @inactive-person roles from all existing roles.

Management

Note that a lot of management enhancements would rely on the implementation of Prometheus life-cycle code, which is unlikely to happen any time soon (and is also subject to development project management considerations).

Note also that references to role management should be understood as two separate processes: the control of which roles a user has, and control of what roles exist. The former has no impact on the existence or otherwise of the roles themselves, and the latter is not directly concerned with assignment of roles to users.

One of the main problems is lack of control over the creation, duration, and deletion of secondary roles (the Toby/Graham action mentioned above is for primary roles only). Secondary roles exist outside the School database (they're stored in Prometheus), and are defined in rfe maps. The user-assignment is handled via Prometheus LDAP. It is the existence of secondary roles, not the mechanism of their assignment to users, that should be tackled by this first action.

One solution to this problem might be to move away from role definition via rfe maps, and move that information into Prometheus - although the rfe maps could still persist and be synchronised (Prometheus does have the capacity to generate rfe role maps from its own data). Within Prometheus, role longevity could be managed using associated start and end dates - although implementing this has its own problems. It's also possible to use role longevity information in Prometheus to manage secondary roles without affecting rfe maps.

Note the distinction between role longevity (which is being considered here) and user-assignment longevity (which is not). Also, determining the lifetime of roles may not be that easy - especially of ad-hoc secondary ones.

It has been agreed that each Unit "should be responsible for the roles/entitlements provision for the services which they provide", and each Unit should therefore decide on - and implement - a suitable management process. It is possible that a common toolset might be produced that could be used by all Units, and thus prevent the re-invention of the wheel. Of course, this assumes that each Unit is happy to use said management tool.

Any management changes should prefer automated or mechanical solutions so as to avoid ad-hoc changes slipping through the net.

The Taxonomy of Roles

One of the problems with roles - if not the main problem - is the difficulty of finding out what roles are available for use, and what they're actually intended to be used for. As stated, roles relate to "who you are", and capabilities (entitlements) relate to "what you can do". The existence and organisation of roles should reflect groupings of people based on actions they need to perform. Obviously, there are some things that all full-account holders will need to do (such as logging-in, and black & white printing), and some things that only a few users will need to do (such as logging-in to restricted-access servers), which would be part of a basic role. These distinctions need to be made explicit and roles organised and assigned accordingly. The "obvious" roles (staff, student, visitor, &c) are - or can be - generated from the School DB (and most are). The rule-set governing the generation of such role names could be amended if it was thought sensible to change (or reduce) primary roles.

It would be very helpful if there was someone to act as roles editor, to co-ordinate role namespace, and to prevent the creation of superfluous roles. Constraining the namespace by a strict naming policy would also help to avoid confusion, and aid identification of useful roles. In addition, a lexicon or database of roles would make selection easier, since it is currently very difficult to decide if any of the existing roles would fulfill particular requirements or if a new role should be created. There is also currently no "info" option/command to show details of a role...

We need to understand the organisational structure to allow informed choice of useful roles. By creating and enforcing a constrained namespace, we would hope to eliminate spurious role creation, and allow a sensible and consistent use of those that do exist. A re-organisation of role namespace along these lines would be a time-consuming task, but one that may well repay the effort. It is this latter action that should be the short-term focus, and was the reason for the creation of this project. The main concern at this stage should be to analyse the current groupings and evaluate their relevance - pruning as much as possible. The ownership of the resulting set of roles could then be assigned, and management procedures established.

Update on deleteable roles:

Redundant roles

  • all primary roles which aren't used (and are unlikely to be used) any more
  • all empty secondary roles, which aren't possessed by anyone

...which are:

all class-* roles (63 of these)

unused empty secondary roles (548 of these):

  • some unused degree-* roles (24 of these)
  • some unused demonstrator-* roles (25 of these)
  • some unused module-* roles (288 of these)
  • some unused new-degree-* roles (40 of these)
  • some unused hci* roles (18 of these)
  • some unused ta-* roles (22 of these)
  • some unused tutor-* roles (25 of these)
  • some unused year-* roles (10 of these)
  • some unused slip* roles (12 of these)
  • sundry other unused roles (84 of these)

...BUT note that the RFE files may contain additional data that would need to be recreated if a role became relevant/appropriate again (for example, database access for a module that's still relevant but not currently taught - and so would be empty).

...there are also subtle interactions with secondary roles (ask Graham about submit & staff roles).

-- RogerBurroughes - 04 Dec 2012


This topic: DICE > RolesRevamp
Topic revision: r22 - 30 Jan 2013 - 14:27:27 - RogerBurroughes
 
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