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 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

Beware fake NHS 'Test and Trace' text messages

May 29, 2020

Please be aware that University staff are receiving fake text messages purporting to be from the NHS coronavirus test and trace service recently announced by the UK Government.

LinkedIn Learning now available for all staff and students

May 19, 2020

All University and College staff and students can now access LinkedIn Learning, which offers a wide range of online courses on creative, technical and professional skills.

View all news