Single Sign On (SSO)

March 19th, 2010

• Tweet
• Share
• Email
• Sharebar

• Tweet
• Share
• Email

Recently at work I have been trying to integrate a MediaWiki’s login with our SSO. My boss explained to me how SSO works. I decided to make a diagram of the way it works and write up a blog post about it. This is a basic overview of SSO. I made an image

Step 1: Step one is the initial request from the client to view a page that requires signing in. When the page receives it checks to see if the client is logged in. Login information is stored in a cookie which I will explain more in the last step. If they are logged in, they are allowed to view the page. Otherwise move to Step 2.

Step 2: Redirect the user to the CAS (Central Authentication Service) server. In the URL used for the redirection urlencode and pass the current webpage as a parameter in the url to the CAS server (Example: https://cas.brokenbytes.info/login/?service=http://admin.brokenbytes.info/index.php). This will be used later (in step 3). CAS provides a login page to the user where they can enter their credentials. If it fails, let them attempt it again. If validation is successful, generate a SSO Token ID (Example: 165asdefASD5). This is a unique token for this single sign on for the client. It will be used for only this session. In memory or a database associate the client with that token. Now move to Step 3.

Step 3: In step 3 the client has just been validated. In this step we need to redirect the user back to the Web Server, but first we must modify the URL to pass the SSO Token ID back to the Web Server. So something like this will be your redirect address: http://admin.brokenbytes.info/index.php?token=165asdefASD5.

Step 4: When the Web Server receives this request, it sees the token variable and then it knows to check the CAS server for its validity. This check to see if the token is valid is between the Web Server and the CAS Server. The client is not involved at all. In PHP you can do this by using file_get_contents(“https://cas.brokenbytes.info/login/validate?token=165asdefASD5″) or similar. If the CAS server replies with an okay, true, yes, etc response then you generate an encrypted cookie for the user to authenticate them. From this point forward they authenticate with the cookie until deleted or time out.

Notes: The SSO Token ID should only be valid for a few minutes or until used and then it should be unassigned.

Downfalls: Session hijacking can still happen because the cookie is stored on the clients machine.

SSO Diagram

[ Tags ]: Single Sign On, SSO
[ Category ]: computer security, programming