As a frequent traveler, I can’t imagine my life without one piece of plastic in my wallet- my Texas Driving License.
On the day of travel, I use it to get past the airport security, get into my rental car, check into the hotel, get cash from my bank (I do not carry any debit cards as a safety measure), get past the paranoid girl at the check out counter who insist on seeing my id before she can swipe the credit card for that bottle of water, prove that I am of legal drinking age as I sit down at the end of day at the hotel bar.
At all of these transactions, I whip out my trusted Texas DL and authenticate myself as Mr. Sachin Jain. Various people look at the id, some run it under various devices which pops up the various security features embedded within the card, almost all look up to match the photo on the card with face and confirm that I am who I am saying I am.
Imagine if I had to carry a separate piece of identification for each of these interaction – the size of my wallet, the hassle I had to go through to ensure that I get a corresponding id that will work at each interaction I will encounter during the trip, and the missed opportunities because I don’t have the ID that is accepted at the most popular joint yelp suggested, or at the hotel I bid for on Priceline as I am walking out of the office on Monday afternoon.
So what happened here is that at each encounter I was authenticated by the system using a token issued by a central/trusted token provider. My Texas Driver License. The issuing authority – the Texas Department of Motor Vehicles.
Once the authentication is done. My identification is confirmed. There is almost always a second piece of token – my boarding pass, notations on the boarding pass giving me premium access, TSA pre privileges, reservation confirmation to a particular car for certain period of time, a hotel booking, my credit card, or plain and simple the my date-of-birth on the DL itself, which than authorizes my access to the service I am seeking.
Similarly in computer security, SSO is a way of authenticating a user based on a Central Directory. When a user requests access to a resource, a certain web site, their HR records, email etc the provider redirects the user to a login page hosted by the SSO authority which presents a challenge-response mostly in the form of a userId/Password combination or additional mechanisms. Once the user gets past this screen, the SSO authority confirms the user authentication and passes a token identifying the user to the servicing application. The application can than bounce this token against its provisioning store and give access to the user to appropriate resources based on the authorization.
Several applications can subscribe to the SSO server, thus eliminating the need for the user to maintain multiple authentication tokens (id/password) to get access. Most of the time if the user has already authenticated once to one application, the SSO provider can leave a token on the browser session so that If you are trying to access another application with the same SSO provider, you don’t have to log in again. Seamless access to multiple application without having to login again.
This is a very simplistic, 10,000 mile high observation of an SSO echo-system, but I hope this helps you grab the basic concept and find similarities/differences between a real life SSO vs a virtual SSO implementation.
Further reading on this topic:
Architect – Oracle Engineered Systems
BuzzClan is a business consulting company collaborating to provide Oracle software advisory services & implementation services. BuzzClan LLC is committed to providing substantive business value on each and every client engagement. We do this through a combination of industry-specific business expertise, technical skills, proven project management methods and our onsite – off site – offshore delivery model. We strive to work in partnership with our customers to build high-performance teams and create business solutions that will last.