All Articles

Top technologies / solutions available for the Single Sign-On are :

1.Common Standard Solutions:

• The Generic Security Service Application Program Interface GSS-API.
• OSF Distributed Computing Environment DCE.
• Pluggable Authentication Modules PAM

 2.Broker-Based SSO Solutions: having one server for central authentication & user account management.                  

• Kerberos: Trusted Kerberos server acts as a broker, centrally authenticates the users and gives them an electronic identity based on the specified credentials.                                                               

• Sesame: Secure European System for Applications in a Multi-vendor Environment is the European equivalent to Kerberos.

• IBM KryptoKnight: It is an equivalent to Kerberos designed by IBM.

3.Agent-Based SSO Solutions: There is an agent program automatically identifying the user for different applications.

4.Token-Based SSO Solutions: The Security Dynamics SecurID is a physical token that generates time dependent one-time passwords for the user thus providing two-factor authentication.

5.Agent and Broker-Based SSO Solutions: When the agent-based solution is combined with a broker-based solution both the central management of the broker-based solutions and the flexibility of agent-based solutions can be used.

6.Gateway-Based SSO Solutions: The gateway remembers the identities of the clients and can thus grant access to all the required services without further authentication requests.

( Read more:  5 easy ways to build your personal brand !)

Pros - Cons of the different type of available technology / Solutions

1.Broker-based SSO

Implementability: The main problem with broker-based solutions such as Kerberos needing the end applications to be modified, or "kerberized" to accept the tickets.

Administration: The central administration is the major strength in broker-based solutions. One central database is easy to manage.

Security: A broker-based solution can be designed to be secure, but the actual level of security depends on the implementation. The authentication in Kerberos is only based on passwords, thus making the system vulnerable to password guessing.  Sesame has mainly the same strengths and weaknesses as Kerberos does, namely the vulnerability to password guessing, and the single-point-of-failure of the Authentication Server. The improvements in cryptography in the KryptoKnight should have made it more secure than Kerberos.

Usage: All the different approaches to Single Sign-On can be designed in such a way that most of the work by the user can be done automatically. Whenever the system has a central component, such as in broker-based solutions, the component is a single-point-of-failure which reduces usage. If that component is down, no-one can log in.

2.Agent-based SSO

Implementation: It makes the migration easier as the software vendor supplies different agents that are designed to communicate with the legacy applications.

Administration: It makes administration harder as there are not just the rights of the users to worry about but also the rights of the agents.

Security: An agent that authenticates itself with strong cryptography should be secure. The problem is that an agent which is "loaded" with identities can possibly be used wrong or replaced by malicious software.

Usage: Approaches such as the SSH Agent that has to specifically be loaded with identities is a hard concept to learn. Also all the concepts of public-key cryptography might be hard to grasp.

( Read more:  How to write a great article in less than 30 mins )

3.Token-based SSO

 Administration: The current token-Based solutions such as WebID increase to administrative workload as one more component is added to the system.

 Security: The SecurID hardware token increases the security of authentication. Less data is available on whether the software tokens can be cracked.

4.Gateway-based SSO

Implementation: In certain environments a gateway is easy to install and configure. The only problem might be the client software for the applications and the gateway client software which need to reside on the same computer.

Administration: The gateway has central user database and thus should be as easy to manage as a broker-based solution. Problems arise though if several gateways are used and the databases cannot be synchronized automatically.

Security: A cryptographic server should be secure but it can be attacked against. It is possible to attack the underlying operating system. As the gateway sits in the place of a firewall, attacks used against firewalls, such as SYN-flooding, might work here, too. It is thus recommended to protect the gateway with a separate firewall.

 Usage: The gateway is a central component that affects the availability and the usage of the system as in a broker-based approach.

( Watch more : 5 Implications of HTML 5 on Security )

5.Agent and Broker-based SSO

Implementation: The purpose of the agents is to remove to need to modify the systems like in pure broker- based approaches.

Administration: The administration of an agent and broker -based solution should be even easier that the one of a pure broker-based solution. This is because even the native databases can be administered automatically through administration agents.

Security: The agent approach should add security as the agents can authenticate themselves without sending passwords, encrypted or not, across the network.

Usage: The solution has a central component that affects the availability and the usage of the system as in a pure broker-based approach.

More:  Want to share your insights? Click here to write an article at CISO Platform

Choose the right technology

Following factors needs to be considered in order to choose the right technology for the SSO.

(1) Smooth functioning & efficient use of the computing resources. Signing-on should really mean acquiring an electronic identity.

(2) Secure and convenient mapping from the physical world to the electronic and logical world.

(3) The intended electronic identity should be given to only that individual it belongs to.

(4) The identification method should not cause extra work by going through the identification process, possibly multiple times.

(5) The system needs to be so reliable that the identity can be proven anytime, anywhere.

(6) As the computing environment has to be administered in some way, the administration should not cause extra work or security holes.

(7) The administration procedures should fit the power structures and policies of the surrounding organization.

(8) When a Single Sign-On system is taken into use, the migration should be easy. All the users should learn to use the system instantly.

(9) The methods of authentication and usage can be distributed and installed throughout the organization without extra effort.

(10) There should be no down-time which would affect normal working. All the applications should instantly accept the new method without any modifications.

- By Vikram Patil, Centre Head-IT Infrastructure, L & T Infotech Ltd.