skip to primary navigationskip to content
 

How Raven works

The Raven server sits between the user and the private web content they are trying to access. The Raven login prompt appears wherever an unidentified user requests access to protected data. Once a user has been successfully identified by Raven, they will not be required to log in again until their browser session expires.

How Raven Works

Overview of the Raven authentication process

The user interacts with the Raven server and establishes their identity by quoting their CRSid and single sign-on Computing Service Password (or specific 'Raven password' if they still have one). Once the user's identity has been established, the Raven server redirects the user's browser to the URL supplied in the request.

What information is sent to Raven?

When a web server determines that Raven authentication is necessary it redirects the user's browser to the central Raven server and includes in the redirection, information relating to the authentication request, including the URL that should be accessed at the end of the authentication process.

What information does Raven return?

Included in the redirect after a successful authentication will be the user's CRSid and possibly other information identifying the user, such as status (staff or student), a personal identifer and other information, depending on the website being accessed.

The web server can then make authorisation decisions based on this information and will cache this locally (perhaps in a cookie, or in session information that it is already maintaining) so that it can process subsequent requests without further interaction with the Raven server.

Raven uses the https protocol

The interaction between the user's browser and the Raven server is over 'secure http' (https). This makes it harder to intercept the interaction and so protects the user's password. It also allows users to verify that they are dealing with the real Raven server and not an impostor.

The interaction between the browser and the webserver may itself need to be over https to protect confidential or personal data, but this it is not required by Raven.

Public and private keys for security

The CRSid and other information contained in the authentication response is protected against tampering by signing it using a private key known only to the Raven server. This signature is verified using the corresponding public key which is widely distributed.

While it is therefore difficult to forge an authentication response, one could be intercepted in transit and replayed if a webserver chooses not to use https. This only affects the security of that particular webserver, however, not the entire Raven system, and is a direct result of the webserver's decision not to use https.

Raven cookies

If the user elects to use single sign-on at the Raven server then it sets a cookie so that connections from the user's browser can be identified in future. This cookie expires when the browser session terminates and is marked only to be returned to the Raven server – and then only over https. The user is not required to accept this cookie, though single sign-on will not work without it.

Last updated: August 2015

UIS Service Desk


  Phone padded  01223 332999

UIS Service Status

Phone padded  Service status line: (01223) 463085
Website  Sign up for SMS/email status alerts
Website  Read major IT incident reports

UIS bITe-size bulletin


A regular newsletter aimed at the University's IT community, highlighting service and project news from UIS.

Sign up >  |  Back issues

RSS Feed Latest news

Lecture capture: Panopto planned maintenance on Saturday 4 January

Dec 09, 2019

Lecture capture recordings will be unavailable during the evening of Saturday 4 January 2020 because Panopto is undergoing an upgrade.

Major upgrade to the phone system during 28–29 December

Dec 09, 2019

The University phone service will be disrupted on Saturday 28 and Sunday 29 December while we perform the annual upgrade of the system's core software.

View all news