This is the 3rd part of my ongoing series of posts about designing a
simple Single Signon System for PHP, you should read part 1 and 2 first.
Today we look a bit more about the general information flow between browser, target web site and the SSO Server. We will use the term Secure Site for the target site, lets say a corporate intranet.
The following diagram shows the flow of information, the information flows via the browser using redirects etc.
First a few words on the requierd bits of information before this exchange can happen.
- The
Secure Site has a pre-shared key (PSK) that the SSO Server assigns,
this key gets hardcoded in the Secure Site and kept private, it never
gets passed between the parties during normal authentication requests. - The Secure Site has a siteid
that is simply a number that uniquely identifies it to the SSO Server.
This too gets assigned by the SSO Server and does not change for the
life time of the site. - Encryption gets done using a simple symmetrical algorithm, the PSK is the passphrase.
- The
SSO server knows what domain name a site is in, the SSO Server will use
this to validate auth requests and generate redirects based on this
domain name only.
Now on to the actual information flow, this demonstrates the flow for a first time visit of an unauthenticated user, future visits will be exactly like any cookie based auth system where the user will not interact with the SSO server at all:
- The user tries to access the Secure Site
- Secure Site generate a unique single use token, and saves it in a Session
- The Secure Site redirect the browser to the SSO server with a request that has the siteid unencrypted and a encrypted string containing the URL the browser should go to if he is authenticated correctly by the SSO Server and also the Token generated in step 2.
- The SSO Server validates the request, checking Next URL against that stored for siteid after using the PSK stored for siteid to decrypt the packet.
- The user is presented with a login form. The login form shows detail about the Secure Site such as its URL, a description of the site and who to contact with any support requests about this site. The user is warned that his personal details will be shared with the site. The user logs in with a username and password and gets redirected to the Secure Site.
- The Secure Site gets a authentication packet in the redirect that has – encrypted using the PSK – the username, email address, real name, time zone and the previously generated token. In unencrypted form is a md5 hash of all the private information concatenated with the PSK, this is signature for the request and could be used as a cryptographic digital signature if the SSO Server is configured to not encrypt the private data. The Token gets removed from the session and the user gets marked as Logged In using a cookie or existing session.
- At this point the user is logged in and can access the Secure Site, the Secure Site knows his private details and can associate his data with him. From this point on it’s a standard cookie based auth and the Secure Site can decide how long the login session is valid for etc.
I think we’ll keep it at that for today, in the next part I’ll explain some of the choices made in designing this protocol and what security exploits it tries to prevent (replay attacks), what it is vulnerable too (man in the middle attacks) and how to mitigate those risks.
