You are here:-, Privacy, Security, Technology, Web Development-Compare FLOSS Authentication SSO Systems for Web Applications

Compare FLOSS Authentication SSO Systems for Web Applications

Introduction

Every website or application requires users to provide their unique credentials in order to sing into their platform. There are a large number of applications and websites that most of the users use these days. In order to sign in to each website, the users will be required to remember the credentials they set while creating their profile so that they could gain access to their profile. The same applies to the applications either the applications are online or in the enterprise. The easiest way that the users can adapt to accomplish this credential thing is to make a file containing the list of all the username and passwords that they kept for all the applications and websites. Each time the user will have to access that list and search for the required credential for specific website or application. It can be quite tiring practice for the users as it might be difficult to remember credentials for all the websites or applications. Another reason for making a list of credentials is that most of the websites now force users to choose some complex password including some digits and special characters, and such password is hard to remember even for one website. However, there is another approach that users can adopt is that they keep the same password for all of the websites and applications, but it might be a threat as if someone gains access to one of the account, he will be able to access all accounts of the users. The best way to tackle this problem is the use of Single Sign-On (SSO) service that handles all the credentials for multiple applications or websites for the users so that the users do not have to enter their credentials for individual applications. Most of the enterprises have multiple applications and users have to log in to applications at least once for one session.

Single Sign-On

SSO is a service that handles the authentication procedures for multiples applications and websites for the users. It enables the users to login only once for one session for all the associated applications that the users granted permission for different platforms. The services help the users to get authenticated with the allowed websites or applications. It can be considered as a centralized system for multiples applications and websites as the credentials to all of them are provided with one server that is SSO service. This concept of centralized identity is also called federated identity.

The federated identity does not only covers authentication process but it further handles more aspects including authorization, user attributes exchange and user management. The authentication module is to validate the users either it is real one or not after verification of the credentials. Furthermore, the authorization module is to validate the permissions to the users for certain resources. For example, this step validates that which websites or applications the user can access if the user tries to other websites then he will not be allowed to do so (Lawton, 2015). Moreover, user attributes exchange handles the data being shared across the different network. However it is important to mention here that SSO is only limited to the authentication module of federated identity, it means that authenticating the systems and sharing the same information with other networks for the authentication process.

Single Sign-On Process

In this section, we will be focusing on how SSO works for most of the applications or websites. The first thing to understand about the concept of SSO is that what if the user has signed in to one of your own websites but when he switches to another site that also belongs to you, then he will have to again sign in and remember its credentials again. However, a better approach for this scenario is that if the user switches from one website to another website by the same company then he should not be asked about credentials again but he should be automatically authenticated for this process. It is better to illustrate the concept of SSO with diagrams (Peyrott, 2015).

The above figure shows the functioning of the user if SSO service is not adopted. In this case, the user will access to domain 1 and in the second step he will be asked to provide credentials in order to get authenticated, after validation of credentials, the user will be authenticated and his cookies will be stored in the browser. At the same time in step 4 the user moves to another domain or website, there will be again asked for credentials in order to get authenticated or gain access to the application or websites. The same method will be applied to all the websites or application the user will try to access and provide credentials every time. It is Non-SSO approach that the users will have to get authentication each time for each session, and sometimes with website policies, if the session expires then the user will have to provide credentials again and then start working. However another way to eliminate this problem is by sharing browser cookies with other domain, but in most of the cases, the browser does not allow sharing of cookies. In order to implement this process, there is also need of a central domain that will share cookies with other domains.

On the other hand, if SSO service is implemented then the whole process will be a lot easier as the service will be handling all the authentication process for all the website that user wishes to use. However, the user will have to first authorize the websites where he needs to take control of SSO service. The following diagram shows how SSO services enable to get authenticated with this services.

Once the user accesses domain 1 in the first step, when it is asked for authentication process then it is redirected to the authentication server in step 2. Where the user is authenticated from the server in Step 3. Once the user is authenticated with the authentication server, its cookies are saved than in the next step the tokens are sent back to domain 1. In this phase, the tokens are used to authenticate the user. In the next step, the domain 1 cookies are stored. When the user access to Domain 2 then the same steps are automatically followed in which the website is redirected to the authentication server where the tokens are sent back to Domain 2 where the same token is used to authenticate the user. The cookies for each domain are stored and authentication process is handled by SSO service so that the users do not have to provide credentials all the time. However, the user might have to provide credentials once for each session (Peyrott, 2015).

There are a number of SSO services being used by different website applications for their own requirements as each of service might be offering different functionality. In this paper, we will be focusing only on those SSO services that are Free/Libre and Open Source Software.

FLOSS Authentication SSO System

There are various single sign-on services that are implemented to be used with web applications. There are many websites that support third-party applications integrated with websites. In this case, the integrated applications require authentication that is provided by the main websites. An example of this integration is that social networking website where third-party applications gain access to those applications. In this report, we will be focusing only on open source single sign-on systems. Some of the open source SSO are Shibboleth, OpenID, Central Authentication System, SourceID, OpenWeb SSO and JOSSO. In this paper, we will be focusing on Shibboleth, OpenID, and CAS only.

Shibboleth

Shibboleth is an open source authentication system that was started in 2000 in order to eliminate issues between organizations that were supporting different mechanism for authentication. Shibboleth supports authentication, authorization, and exchange of information. It is based on Security Assertion Markup Language that is based on the XML based system. It operates on 3 components; IP, SP, and WAYF. The first part is Identity Provider (IP) that handles the assertion for authentication and it can share some information with Service Provider (SP) as well. The information that is meant to be shared with SP contains only limited information like the age of user and rest of the information is not required by it. On the other hand Service Provider manages the resources that are protected depending on the information provided by the IP. Lastly, WAYF stands for Where Are You From that is used to select IP and it can be said to be the middle step between IP and SP (Anon., 2012).

When the user requests to view a page with Shibboleth, then it is redirected to SP to check if the user is authenticated or not, if the user is not authenticated then SP redirects the user to WAYF server for user authentication. In WAFY there is a list of IP that enables the user to select its own IP and from here the user is redirected to select IPs’ page. If the user is already authenticated then it might happen another way as well that the WAYF server is not involved and redirected to IP. In IP the authentication is done by a form where SP sends information back to IP to validate the authentication of the user. Once the user’s authentication is validated, then again SP will ask IP for necessary attributes and then IP returns those attributes and requested page is displayed. This process is not repeated every time, even if the user requests for another page SP will not ask for authentication. This authentication is required once per session.

OpenID

The second open source SSO is OpenID that manages authentication and authorization. Most of the global enterprises use it for authentication purpose, companies like Yahoo, Google, and PayPal. This protocol was developed in 2005 and it was adopted by the industry because of its decentralization and no need for being approved by any organization. It can be seen how popular it was that by the end of 2009 around 9 million websites were using it (Anon., 2012). There are two components of OpenID; Replying Party and OpenID Provider but not any server like it existed in Shibboleth. In this authentication process, three components are involved, User, RP, and OP.

 

In the first step, the user request login with a page that has OpenID implementation, in return RP sends back a login form to the user. This login form only contains the OpenID identifier that the user is aware of but no password field. In the third step, the user sends back its user identifier in order to login to page, and the open identifier might be in URL or XRL. One more thing that this identifier includes for OpenID to work is that it must contain openid_identifier to support the browser extension. In the fourth step, RP sends the authentication request to OP and also redirects the user to OP authentication page. Moreover, it is an indirect request it means it might use one of the methods, HTTP redirects or HTTP form submission. There should be some parameters included in authentication request; openid.ns or openid.mode. In the next step, the user authenticates itself with OP. In sixth step, OP sends assertion that contains the information relevant to the authentication of the user either successful or failed. The last step of OpenID authentication is that again RP verifies the information including return URL and signature.

CAS

Central Authentication System was developed in 2004 as a tool that is easy to use. It is also an open and free service that consists Java Server components that help in communicating with the clients written in different languages. There are two components of this authentication system; CAS Server and CAS Client. A CAS client can be called as a service provider that is enabled to communicate with CAS server or it is a software package that can be integrated with other software’s so that it can communicate with the server for the authentication process. On the other hand, CAS Server is that issues ticket for the authentication process, and it knows the password of the users. It not only authenticates the user but also transmits the identities of the users that are authenticated users of CAS clients (Rouse, 2016). The user requests for authentication to CAS server, and the server issues a ticket when the login process is successful. The ticket is validated by the CAS client through communication at the back end.

Comparison between Shibboleth, OpenID, and CAS

Considering these three single sign-on services we can see that most of them offer both authentication and authorization process. However, it is an addition but not required at all. Even OpenID is supposed to be providing authorization process but that also requires authentication process that makes is SSO as well. They offer great compatibility to most of the platform that is implemented most of the websites and applications. Shibboleth and OpenID offer authentication and authorization functionality but CAS does not offer authorization process. It only offers authentication process (Claudio Agostino Ardagna, 2006).

The main difference between these SSO services may depend on the way the work and carry out authentication processes. OpenID, however, is best as it is being used by most of the organizations and it does not involve any server in order to get authentication process complete. However, these services are great but it depends on the requirements of websites and application that need to implement it. If it was to decide which one to choose then it might depend on what type of tokens they issue that can be integrated with the websites.

Shibboleth SSO uses OpenSAML (Security Assertion Markup Language) that is a set of C++ and Java libraries and it can be easily used with most of the web applications. On the other hand, OpenID is also supported by most of the languages (Rouse, 2016). The most important factor for the implementation of SSO is that the services should be secured, and all the three aforementioned services are totally secure and they can be implemented without any hesitation. OpenID is mostly preferred because it is totally independent and it does not require to be authorized by any organization.

Conclusion

Single Sign-on service is a solution to the authentication services that allow users to switch between different web applications and websites without providing credentials each time. SSO is being adopted on a larger scale not only for the web applications in the industry but also by the enterprise who have a number of applications to be operated on a daily basis. If the users have to provide credentials for every single application every time it accesses that application then it would cost more to enterprises and waste time as well. Moreover it free employees and users from the trouble of remembering the password that they have for different portals. They do not have to manage those passwords in a list and look for a password each time to access the portal. SSO takes care of all the credential work and makes the processing more productive. However, it cannot be said that which one is the best SSO that can be implemented in every environment, it is because every SSO offers different functionalities and have own protocols. There are paid and free SSO that allows the users to choose the best that suits their requirements.

Bibliography

Anon., 2012. Analysis and Implementation of a SSO Solution for Several Web Portal. [Online]
Available at: upcommons.upc.edu/bitstream/handle/2099.1/16003/78142.pdf?sequence=
[Accessed 2 9 2016].

Claudio Agostino Ardagna, E. D. P. P. a. S. R., 2006. Adopting Open Source for Mission-Critical Applications: A Case Study on Single Sign-On. Boston, Springer.

Dennis, Z., 2013. Choosing an SSO Strategy: SAML vs OAuth2. [Online]
Available at: https://www.mutuallyhuman.com/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
[Accessed 2 9 2016].

Florian Holzschuher, R. P., n.d. Approaches and challenges for a single sign-on enabled extranet using Jasig CAS. [Online]
Available at: http://subs.emis.de/LNI/Proceedings/Proceedings223/106.pdf
[Accessed 1 9 2016].

Heijmink, N., 2015. Secure Single Sign-On A comparison of protocols. [Online]
Available at: http://www.ru.nl/publish/pages/769526/z_researchpaper_sso_final_nick_heijmink_s4250559.pdf
[Accessed 2 9 2016].

James, S., 2007. Web Single Sign-On Systems. [Online]
Available at: http://www.cs.wustl.edu/~jain/cse571-07/ftp/websso/
[Accessed 2 9 2016].

Lawton, S., 2015. Secure Authentication With Single Sign-On (SSO) Solutions. [Online]
Available at: http://www.tomsitpro.com/articles/single-sign-on-solutions,2-853.html
[Accessed 5 9 2016].

Peyrott, S., 2015. What is and how does Single Sign On work?. [Online]
Available at: https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/
[Accessed 2 9 2016].

Rouse, M., 2016. single sign-on (SSO). [Online]
Available at: http://searchsecurity.techtarget.com/definition/single-sign-on
[Accessed 1 9 2016].

Sandil, A., 2016. SSO Strategy: Authentication (SAML) –vs– Authorization (OAuth). [Online]
Available at: https://www.linkedin.com/pulse/sso-strategy-authentication-vs-authorization-saml-oauth-sandil
[Accessed 1 9 2016].

Storani, M., 2008. Single sign-on (SSO): Concepts, Methods and Frameworks. [Online]
Available at: https://mauriziostorani.wordpress.com/2008/07/21/single-sign-on-sso-concepts-methods-and-frameworks/
[Accessed 5 9 2016].

 

About the Author:

Leave A Comment