Skip to main content

Single Sign On - SSO


   Single Sign On (SSO) is the ability of the user to login into his/her system or network and have access to all the applications which he is authorized to under the Lightweight Directory Access Protocol (LDAP). Another good definition is given on this page .A website with many links to SSO is defined here.

  What is Authentication?
         Authentication is the process of verifying or validating the user and password against some security processes.

   What is Authorization?
         Authorization is granting access (roles) to each user for a specific application.

Consider a company of say ten employees which contains an accounting system and a human resources system. Each user is authenticated and authorized on the company network to access public folders, intra-net, and possibly webmail.

However, only the HR department is authorized to access the HR system. Similarly, the Accounting department is authorized to access the accounting system. There is also a possibility that certain users in the HR department can access both the HR system and Accounting system. This also holds for certain accounting department personnel.

The user id and password are generally stored in the LDAP system. For each application, it is possible to define the roles admin privileges, read/write privileges, and read only privileges in LDAP as well as assigning the roles to each user. This is shown for an application in the diagram below:

          The above picture shows us how a user is authenticated and authorized with everything defined in the Client LDAP.  We do not check if the user is authorized to use the application in the application. Although this is a preferred approach, it does have its disadvantages. Maintaining the LDAP is practically a full time job as an administrator. Defining new roles for a new application and assigning each user correctly are time consuming. One advantage is some features, like groups, are available to combine certain roles for different applications and assign them to the user.

           The simplified version of SSO is to store all the roles inside the application for each user and use LDAP only for authentication to the network and similarly for the application. This is Single Sign-On Authentication (SSO-Authentication) as shown in Figure 2 below.

           The SSO-Authentication has been used in many places as the roles are defined inside the Application rather than the Client LDAP. This is easy to maintain and implement.

       With the implementation of roles in the second approach, many vendors have started storing user id, user assigned roles and the role definitions in a relational table. However, most implementations do not consider groups in the authorization method. The authorization is left at the application level. Therefore, each user is again defined with the role they are granted in each application. 

           Another feature for most SSO- Authentication is that if the user logs out of the application, then the application should go back to the login page of that application. This enables the user to login as a different user than the user logged in on the laptop/network. This is becoming increasingly common and with the integration of applications at client sites, vendors must take this into consideration.

         This article is the outcome of implementing LDAP with applications and roles defined in  the LDAP which is shown in Figure 1. This methodology is becoming obsolete due to the complex nature of defining roles every time an application is bought. The second approach is being implemented by more and more companies which is shown in Figure 2. It is common to hear people using SSO and only mean SSO-Authentication.

         SSO-Authentication is also called Single Log On (SLO). After a few implementation of LDAP groups and roles in production that it gets very complex to maintain roles/groups in LDAP directory. With that being said many architects prefer to write their own authorization and use LDAP directory only for SLO.


Popular posts from this blog

Hibernate-Secondary Table Annotation..

When using Hibernate with annotation, SecondaryTable needs to be used carefully while using the Discriminator. We assume that there is a table called Inventory which is the parent table that has common elements including Id, createDate, modifiedDate, SKU#, and productType.
The other tables, which are children of the Inventory table, are TV_Inventory, DVD_inventory etc.. In this example, we consider TV_Inventory which inherits from Inventory (in terms of objects).

@Table(name = "INVENTORY")
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name = "PRODUCT_TYPE", discriminatorType = DiscriminatorType.STRING, length = 20)
@SequenceGenerator(name = "InventorySequence", sequenceName = "INV_SEQ", allocationSize = 1)

public abstract class Inventory {
 // getters and setters with other annotations for the columns and relevant methods.

Consider the child object associated with the table TV_INVENTORY. The outline is shown below:


4 Circles releases Word Frequency..

4 Circles released its application 'Word Frequency v1.1'.

This application counts the number of words in your essay and tells you the frequency of each word. This application is simple to use and helpful for bloggers, writers, journalists, students and speech writers. The application has 1 box for the text to be copied and pasted (left hand side) while clicking the button will count the total number of words in the essay.

This application is written in JDK 1.6, and runs on JRE 1.6.x or above. The user needs to copy the text and place it in the text box and click on the button to get the frequency in the grid. Please download the software here:
Word Frequency