SSOv2
Cookie Security Improvements
Since April 2019, we have set the Secure flag on the WarwickSSO
cookie. This requires any sites using SSOv2 to be served in a secure manner (that is, using HTTPS) in order for the user's browser to send the SSO token.
SSOv2 is currently the most widely used version of SSO, but is less flexible and has various limitations. One of the limitations is that it only works for applications under the warwick.ac.uk domain. We are gradually helping people move over to the more powerful and secure SSOv3, although some simpler applications running on campus may be better off using the simpler SSOv2.
We provide a Java API for working with SSOv2 called Userlookup. When using SSOv3 you may still use the UserLookup interface to find information about users by their user ID.
SSOv2 basically just provides interfaces for the following:
- Logging in a user (requestType=2)
- Logging out a user (requestType=3)
- Getting user information from their login token (WarwickSSO cookie) (requestType=1)
- Getting user information by the usercode (requestType=4)
Request types 2 and 3 (login, logout) are discouraged. You should send the user to the websignon login and logout URLs rather than collect the username/password yourself.
The standard pattern for using SSOv2 is this:
- If there is no WarwickSSO cookie, point the user to the built in SSO login screen
- User logs in
- User is returned to your application
- You read the value of the WarwickSSO cookie and get the user details from the getUserByToken interface
- User uses your application
- User optionally clicks on a logout link pointing to our logout screen
At step 1, if there is already a WarwickSSO cookie, you can check it with the getUserByToken interface and may find that the user is already signed in from using another application.
Text encoding
By default, sentry responses are encoded using the ISO-8859-1 character encoding which is only capable of representing a limited set of characters.
As of 13th March 2019, you can opt into UTF-8 responses by setting the Accept-Charset
request header to indicate a preference for UTF-8:
$ curl "https://websignon.warwick.ac.uk/origin/sentry?requestType=4&user=u1234567" -H "Accept-Charset: utf-8"
For backwards compatibility, UTF-8 responses will not be returned at present unless explicitly opted into by the client.
Sequence diagram
The general flow is illustrated in the diagram below: