skip to content

Since July 2013, Raven accounts have not been cancelled when people leave the University, although their other UIS accounts have been cancelled as usual. This page details the effects of this change for webmasters using the Raven service.

Why were these changes introduced?

Prior to this change, Raven accounts were only available to people matching some interpretation of "current staff and students of the University and Colleges, and accredited visitors". Since the Summer 2013 main user purge, Raven accounts have not been cancelled when people leave the University, although their other UIS accounts were cancelled as usual.

The immediate benefit was to allow University leavers to maintain the 'tombstone' email address in Lookup that is included in the rejection messages sent in response to messages to the user's cancelled email addresses. There are currently no plans to extend Raven authentication to other groups – doing so is a policy and resourcing issue that will be addressed by UIS senior management in due course.

We were aware that many sites relied on the "current staff/student/visitor" restriction as a convenient (if inexact) way of granting access only to people 'inside' the University (e.g. by using 'require valid-user' in Apache). The increasing Raven population would have been a problem for many such sites, had we not introduced the measures outlined below:

What has changed?

  1. The Ucam WebAuth server provided by Raven has been enhanced so it can distinguish between "current" people (i.e. people who would have been entitled to a Raven account under the old rules), and everyone else.
  2. All existing Ucam WebAuth clients (e.g. mod_ucam_webauth) use Ucam WebAuth protocols 1 or 2. The Raven WebAuth server will not respond to an authentication request over protocol version 1 or 2 with a successful authentication response for anyone not considered "current". "Non-current" people are still be able to login to Raven, but they receive an error page from the Raven server itself explaining the situation. The page carries a single button labelled "Cancel" - selecting this has the same effect as selecting "Cancel" on the Raven login page.
  3. The Raven Ucam WebAuth server now additionally supports version 3 of the protocol. Using this version of the protocol has two effects:
    1. The Raven server will return a successful authentication message in response to a protocol 3 request for anyone, "current" or not.
    2. The response message includes a new 'flags' field which contains the value "current" for anyone the Raven server considers to be "current", and which doesn't contain it otherwise.
  4. Version 2 and above of the Apache mod_ucam_webauth module (available from here) support version 3 of the protocol. By default, the module will reject authentications by people not considered "current" (so preserving the previous behaviour), but a configuration directive is availale to override this. The module also allows the error message presented when a "non-current" person is rejected to be customised.
  5. For the time being, the Raven Shibboleth service will continue to provide authentication services only to "current" people. In due course it will be adjusted to authenticate "non-current" people as well, although it will assert very few, if any, attributes about them. At that time, anyone relying on a successful Shibboleth authentication to mean "current" (i.e. using '<Rule require="valid-user"/>' in shibboleth2.xml, or just 'Require valid-user' in Apache) will need to make minor configuration changes if they want to exclude "non-current" people. Further announcements will be made about this issue.

What are the effects of this change?

Sites previously using the Ucam WebAuth protocol to interact with Raven should have seen no change and will have continued to receive successful authentications only from "current staff, students and accredited visitors".

Sites using Ucam WebAuth that want to authenticate additional people need to upgrade their Ucam WebAuth support.

Sites using Shibboleth will have seen no immediate change, but will need to make minor configuration changes if they want to continue to limit authentication to "current staff, students and accredited visitors".

Last updated: August 2015