Single Sign On or SSO

With SSO, users don't need to remember each password for each service providers. When you authenticated to a universal authentication sign-on service, your service provider relies on the information from the SSO server.

For example, you want to use the services from example_flightbooking.com, a web site which provides services for booking flights online. This site accepts your credit card and other personal information and you expect it must be kept secured.

Let another sevice which you would be using in conjuntion with flight booking be a accommodation booking service where you would want to book your accommodation at the place where you are flying to, using the web site, example_hotelbooking.com. This site provides services for you to view and book hotel rooms online. Authentication to this service provider is done by providing a separate user name and password same or different from example_flightbooking.com

If the user chooses to use same User ID and Password for these two sites, there comes a major risk. If one of the site is fraudulent or an attacker obtains the User ID and password by means of social engineering or phishing, he can use this User ID and password for both the sites and can obtain personal information stored in these sites, along with Credit card and other vital information.

Alternatively, if you choose to different User IDs and passwords with each of the service providers, users have the burden to remember all these login credentials. Chances are there for using same credentials or easily- compromising credentials.
Single Sign-on helps to reduce this problem to a great level. With this Universal Authentication service system, both Users and Service providers (like example_flightbooking.com, example_hotelbooking.com) trust this system.

There are a number of steps for successful enrolment and using the SSO. First Service Providers should be enrolled with SSO servers by means of a contract. Some SSO needs a fee to use their service. Secondly, users who wish to use services from
Service providers also need to be enrolled with the SSO. Whenever a service provider needs a user to be authenticated to use their service, the service provider redirects the user to the SSO login page. User provides the credentials he/she registered with the SSO. ON successful login, SSO issues a ticket or a cookie etc, and these are generated using cryptographic means. An example can be a shared key between the Service provider and the SSO. After this step, when the user accesses the Service provider’s site, the ticket from the SSO is provided which will be verified by the service provider (here, as we mentioned, by a shared key). If it has been verified as issued by the SSO, the user is authenticated.

Examples of SSO are MS Passport system which supports Kerberos protocol to issue a ticket to the service provider.

Advantages for the user are it helps to eliminate remembering various passwords. Also, they can trust a service provider as their enrolment with a SSO system gives some trust to the end user.

Disadvantage could be the SSO is a single point of failure.