Single sign on: a possible solution

The common ICT-environment has gradually developed into an environment with multiple applications. Furthermore, security has gained considerable importance, thus more and more applications ask for a username and password. The average user will be confronted with several usernames and passwords and every system uses a different username- and password policy.

The user has to remember all of these, which can prove to be difficult. Occasionally, people use Post-its to keep track of the different usernames and passwords. This ‘system’ nullifies the security, because all the information can be read easily by others. The ‘Post-it’ problem is not novel. It can be solved with a single sign on, but the sso-playing ground has experienced several changes.

The ideal solution

One central authentication source is the ideal solution. Every application and system will utilize this central authentication source. At the workplace, a user logs in and will be granted access to the other systems based upon these credentials.

An example of this can be observed within a Microsoft only-environment. The Active Directory is used as the central authentication source. Systems such as Windows File Server, Exchange and/or SharePoint are able to log in the user automatically based upon their Active Directory Account.

This assistance can be extended to systems that support the techniques to connect to Active Directory. Kerberos, LDAP, ADFS or SAML are used. For systems that do not support these, an advice could be to utilize an add-on, such as the Quest Authentication Services.

One user, one password

Not every system uses these principles, thus, there are quite a lot of applications where the user has to utilize another username and password. If this is the case, it is possible to apply a synchronization on the usernames and/or passwords. The user is able to utilize identical usernames and passwords for each system and is no longer obliged to remember the different usernames and passwords.

This can be arranged easily with a password synchronization tool. With this tool, the passwords belonging to the different systems will be transformed into the same password. Tools4Ever provide such a solution, but this is quite a straightforward version. Complexity increases if an identity manager is utilized. If that is the case, not only the password will be transformed, but the username as well.

There are several providers regarding an idm (Identity Management) or iam (identity access management) solution. Powers, such as Microsoft, Oracle and IBM, provide an iam-solution. Smaller companies, such as Tools4Ever, provide their own iam-solution as well. There are many options, but all these products are difficult to implement.

Specific rules apply to every application regarding the username and password, and this has to be equalized before starting an iam. Furthermore, it has to be verified if the iam can be connected to the different systems. Which drivers should be developed to present a username and password within a system? In every system, changes in passwords or other adjustments have to be processed. The iam has to be programmed per action, per application, for example the producers responsible for new employees, ex-employees and changes in function.

An iam cannot prevent a user having to log in once again for every application, but it does take care of equalizing all the different data. A user does not have remember all the different usernames and passwords anymore and, subsequently, will be less likely to use the ‘Post-it system’.

E-sso

For iam/idm, it is necessary to have the permission to read and write in each system. However, this is not by definition possible. It can be technically impossible, but most of the time it is a problem regarding rights. If you use an authentication system managed by another company, writing permission in that system is not granted automatically. If this is the case, the iam will not function.

For this purpose, you can use an enterprise single sign on-solution (e-sso). The difference between sso and e-sso is that the sso refers to a work-based infrastructure solution. Sso implies using one username and password to gain access to all information sources. Sso makes no statements regarding the used technique. With an e-sso, at the workplace of the user, a client functions that interferes when a username and/or password is requested. In practice, these two abbreviations are used interchangeably. It is advised to check what is meant when someone is speaking of a sso.

Thus, e-sso functions as client-software on the user’s desktop. There is no difference between a fat client, Citrix server or vdi. The first time the application will initiate, the e-sso client will monitor and save the username and password. Subsequently, the e-sso client will automatically enter the password and username and press continue each time the application starts. If an adjustment of the password has to be made, the e-sso will be able to do this. However, the user is no longer aware of the password, which is a limitation. The advantage is that passwords of increased complexity can be used. The e-sso will create a random password. As administrator, you will determine the rules for creating the password.

Prominent e-sso-solutions are NetIQ’s SecureLogin, Imprivata’s sso, Tools4Ever’s e-ssom and Quest’s e-sso. These tools operate, at the base, in the same manner. On a central console, the administrator defines the different applications. This is where the log-in fields, changing the passwords fields and so forth are identified. These definitions are then distributed to the e-sso-client. Each solution includes its own extra functionalities supplementary to the solution.

Is sso safe?

Sso improves the security because users are no longer confronted with a myriad of passwords. A user has to remember a single password; that of his primary login account. This is where the limitation of the sso lies. If I know the information belonging to his primary login, I will be able to login to every other system he is permitted to view. Thus, it is advisable to use a two-factor authentication when utilizing sso.

Sso solves the ‘Post-it’ problem, but does not know the inns and out of the systems behind the login. The moment the user is beyond the login, the sso will no longer function. A user will still be able to copy and distribute information in the system. Sso is a part of the information security policy and can improve the security, if it is operated correctly.

Conclusion

The type of sso that fits an organization depends on the ict-infrastructure. If the applications come from the same provider, it is possible to utilize one central authentication source. That will not do for most companies. Then, it should be examined if the different sources can be connected. Thus, it is important to inspect the different access methods to different sources. Is it possible to equalize all the passwords and usernames by using the iam? An iam will take care of the equalization of all the passwords and usernames and of applying these adjustments universally. The implementation of an iam can prove to be complex, expensive and time-consuming. An e-sso-solution is especially suitable for environments in which different authentication sources cannot be connected.

Martijn Bellaard has been working for TriOpSys as a lead architect for 3 years. At the beginning of 2017, he has pursued his life-long dream and has become a teacher at the Hogeschool van Utrecht. This article has been published on 27-02-2015.