Current and non-Current users: Difference between revisions
(Created, based on the cs-raven-announce posting) |
|||
(One intermediate revision by the same user not shown) | |||
Line 12: | Line 12: | ||
Sites previously using the Ucam WebAuth protocol to interact with | Sites previously using the Ucam WebAuth protocol to interact with | ||
Raven should have seen no change and will | Raven should have seen no change and will have continued to receive | ||
successful authentications only from "current staff, students and | successful authentications only from "current staff, students and | ||
accredited visitors"; sites using Ucam WebAuth that want to | accredited visitors"; sites using Ucam WebAuth that want to | ||
Line 50: | Line 50: | ||
## 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. | ## 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. | ||
# Version 2 and above of the Apache mod_ucam_webauth module ([http://raven.cam.ac.uk/project/apache/ available from here]) support version 3 of the protocol. By default the module will itself 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. | # Version 2 and above of the Apache mod_ucam_webauth module ([http://raven.cam.ac.uk/project/apache/ available from here]) support version 3 of the protocol. By default the module will itself 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. | ||
# For the time being the Raven Shibboleth service will continue to only provide authentication services to "current" people. In | # For the time being the Raven Shibboleth service will continue to only provide authentication services to "current" people. In due course it will be adjusted to additionally authenticate "non-current" people, though 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 f they want to exclude "non-current" people. Further announcements wilTest and Demonstration Serverl be made about this issue. | ||
due course it will be adjusted to additionally authenticate "non-current" people, though 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 | |||
To enable support for this functionality to be tested, [http://raven.cam.ac.uk/project/test-demo/ Raven's 'Test and Demonstration Server'] has been reconfigured so that its user-ids test0001 to test0400 are marked as belonging to 'current staff and students', leaving user-ids test0401 to test0500 not so marked. |
Latest revision as of 12:04, 3 December 2014
This is a slightly edited copy of an announcement to the cs-raven-announce@lists mailing list, originally posted on 27 June 2013
Executive summary
In mid-2013 the rules about who is eligible for a Raven account changed, allowing Raven to authenticate more than just "current staff, students and accredited visitors". This message describes these changes and how the Raven service changed as a result.
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".
Detail
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". As from the summer 2013 main user purge, Raven accounts have not been cancelled when people leave the University, though other UCS accounts are be cancelled as usual.
The immediate target for this is to allow people who have left to maintain the 'tombstone' email address in Lookup that is included in rejection message sent in response to messages to cancelled @cam.ac.uk 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 the UCS's senior management in due course.
We are aware that many sites rely 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 taken the following steps:
- 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.
- 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.
- The Raven Ucam WebAuth server now additionally supports version 3 of the protocol. Using this version of the protocol has two effects:
- The Raven server will return a successful authentication message in response to a protocol 3 request for anyone, "current" or not.
- 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.
- 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 itself 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.
- For the time being the Raven Shibboleth service will continue to only provide authentication services to "current" people. In due course it will be adjusted to additionally authenticate "non-current" people, though 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 f they want to exclude "non-current" people. Further announcements wilTest and Demonstration Serverl be made about this issue.
To enable support for this functionality to be tested, Raven's 'Test and Demonstration Server' has been reconfigured so that its user-ids test0001 to test0400 are marked as belonging to 'current staff and students', leaving user-ids test0401 to test0500 not so marked.