Monday, July 2, 2012

Single Sign On (SSO) with SAML




The pace at which our number of usernames and passwords increase every year is enormous. With each new account we have a new dimension of security associated with it. On the organizations perspective, multiple accounts cause security problems and huge storage and management issues too. With cloud infrastructures increasingly becoming popular, these problems are escalated. Single Sign on (SSO) is therefore a popular infrastructure for organizations today. If you see Google, with one login, you can access Gmail, Google Drive, Youtube, Google Calendar, Blogger and other services that it offers. The latest one is the browser Google Chrome’s cool support which enables you to sync your bookmarks, extensions and even live pages all using just the same account.

Benefits of using SSO:     
1. SSO reduces password fatigue which is caused due to entering different username and password     combinations. 
2.It provides a centralized infrastructure for managing and storing of account details. This in turn reduces IT    related costs.
3.It also reduces the cost for setting up IT help desks for password losses.  It provides easier access to resources.
4.It makes security management much easier by having a single layer of security which is more generalized for each service or application.
5.Tracking users and tracking their access to resources becomes easier.

There are different single sign on configurations that exists.


   - One time Password (OTP): OTP is one of the most secure ways to do a Single Sign On. There is a two factor authentication using special OTP tokens which is one of the best practices in the industry today.
     
   - Kerberos based SSO: Kerberos has ticket granting servers. The initial sign on grants you access to the Kerberos system. Other different services are all accessed by requesting for tickets for that particular service.
     
   - Security Assertion Markup Language (SAML): SAML is a XML-based solution for exchanging user security information between your organization and a service provider. It supports W3C XML encryption and service provider initiated web single sign-on exchanges. The user is called the subject in the SAML based Single Sign On. The identity provider is the one which provides the user credentials. The service provider trusts the identity provider on the user information to provide access to its services or resources.



More on SAML:
A transaction from an identity provider to service provider is called SAML assertion. SAML assertion structure is defined using an XML schema which is specified under the OASIS SAML standard. It contains header information, the subject and attributes for the subjects which are the statements for the subject and conditions. The identity provider sends a certificate to the service provider on Login. This certificate is a proof that the data entered by the user is valid and based on this certificate the service provider grants the user access to the service. The certificate usually contains the signature of the identity provider and other attributes which were setup during setting up of the Single Sign On feature which were decided by the Service provider. Force.com uses SAML for Single Sign On.  It is a very modular way to implement SSO.



OAuth - Best Security and Best Privacy




Security is one of the key concerns in the online world today. The tech world knows about the recent compromise of security where various LinkedIn passwords were hacked. Usually a large website like google.com or Salesforce.com has various other websites linked to them which belong to the same or different organization like gmail.com, blogger.com or Force.com, radian6.com. To login, we enter our credentials into the main website and then, we are redirected to the respective websites that we want to go to. In today’s world this is enabled by security tokens which are shared between websites.

The above scenario is made possible using an open protocol called OAuth. OAuth allows a website to access another website without exposing a user's credentials. OAuth allows users to give out tokens for other websites to access limited resources for a limited time. This is done using tokens and consumer secret keys which are exchanged between the websites and users. This is useful because even if a website security is compromised it gets only the tokens and consumer keys which could be revoked. So the credentials are safe. 

OAuth has two types of tokens, request token and access token. We have a user and an application or a service (consumer) which wants limited access from a website where the user has his login credentials. The service will first ask for a request token from the website (say Salesforce). This token has a consumer key and a consumer secret key. The request token redirects the user to the website, where he enters his credentials. The user logs in and the consumer now gets access to the website without the user having to provide his credentials to the consumer. Consumer gets access after the user formally approves giving access to the consumer. After the user approves the request, the website marks the request token as approved by the user. The authorized request token is then exchanged by the consumer for an access token. There may be multiple requests using the access token, to finally get what the consumer wants. This continuous exchange of tokens is sometimes termed as OAuth dance.  All the tokens are time stamped and hence, the consumer gets limited access. Also, the consumer never gets the actual user credentials.  This improves privacy as well as security.

To learn more about OAuth: