Report on roles & capabilities

Quick Overview

Roles are (or were intended to be) ways of describing sets of permissions, based on a category a person belongs to - in short, "what you can do" relates to "who you are". Role names, therefore, are (or should be) descriptive. Each role has associated sets of permissions ("capabilities", "entitlements"), describing what can be done by someone with that role (although this, in itself, is not sufficient to constrain actions - the implementing application has to check).

All roles are defined by a corresponding rfe map, regarded as primary if named in the School DB, and secondary otherwise. The DB generates the primary role names, but does not create the roles - the rfe map is manually created in both cases.

We have approximately 1350 roles, consisting of around 200 capabilities (excluding the group-triggering "group/*" ones). Roles may contain other roles.

So what's the problem?

There are too many roles. They lack coherence and are not deleted when no longer needed. 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.

Because of a lack of co-ordination, the use of roles has become inconsistent and, often, misleading.

What should we do?

Namespace

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

We should (if appropriate) examine all capabilities to make sure that there are no redundancies or inconsistencies. Any ROLES that are not used by other roles or by users should be deleted. Any CAPABILITIES that are not used by other roles or by users should be deleted (but this is likely to be quite a time-consuming task). This is not to say that any such roles may not exist in the database but - pending an automatic creation and deletion mechanism - the namespace should be as sparse as possible to cut down on administrative overhead. Note that there is an action to investigate the automatic creation of rfe maps for modules

We should sort out the over-inclusion of the @person role - this is currently included in too many inappropriate places. This has now been done.

Functional categories

In order to automate account creation, some roles 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.

Implementation

There was a great deal of discussion about what should happen, some of which is distilled below (in the Management Recommendations section).

As far as tidying-up went, the following was carried out:

  • checked for comment-free unused empty secondary roles (only a few found, so no action taken)
  • identified & removed all class-* roles
  • identified & removed all year-* roles EXCEPT year-{msc,ug[12345]}
  • removed @inactive-person role (effectively just "@person") from the modules-* and year-* roles (this is a significant part of the "@person over-inclusion" problem)

Note that assessing which roles can and should be deleted is not a simple matter, and we need real-world investigation to determine which of the role deletions are, in fact, uncontentious.

Management Recommendations

One of the main problems is lack of control over the creation, duration, and deletion of roles. A more structured set of management procedures is needed to fix this, possibly allowing for (or enforcing) the start & end date for user-possession of secondary roles (primary roles already have implicit user-related duration information which can be derived from the database). At present, there is no automatic removal of secondary roles from a user when these are no longer applicable. The cost of implementing this needs to be measured against the benefits of a more robust and controlled management of secondary roles. However, this is closely linked with the Prometheus life-cycle code that is currently being developed elsewhere, and further modifications should be fed into this process.

To aid current roles management, it is possible for Prometheus to generate lists of roles which are defined (via an rfe map) but not allocated to users, and roles which are allocated to users but not defined.

To break the inappropriate linkage between person status and eligibility for an account, it is proposed to remove the basic account-giving entitlements from the @active-person role and move them into a "full-account-holder" role, which can then be included in relevant higher-level roles.

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 could 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 such a management tool. It would also be helpful if this Unit-based management was co-ordinated with other Units through a roles "editor" (a real person) to co-ordinate role namespace, and to prevent the creation of superfluous roles. It would be hoped that such a role would not be too onerous, but would be beneficial and a way to make sure that some consistency of role structure and usage was maintained - there is currently no easy way to establish what existing roles are for, nor to make sure that they fit appropriately into role namespace.

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

The name of the 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 database tools, since the database holds the definitive copy of the relevant data.

Role/capability/entitlement names should have a standard format (insofar as such a thing is possible). This (hopefully) makes the identification of roles with similar/duplicate functions easier.

-- RogerBurroughes - 21 Mar 2013

Topic revision: r2 - 26 Mar 2013 - 10:53:57 - 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