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