Single sign-on (SSO)

It is well known that a large majority of companies are active on social media, and/or use the ad­vant­ages of cloud services, and also mobile devices such as smart­phones and tablets. These forms of tech­no­logy have long since become an integral part of everyday working life. This means a whole lot of passwords that you have to remember – in addition to those you already have in mind for your private e-mail and social media accounts.

It’s no surprise, then, that the everyday web user suffers from a serious case of chronic “password fatigue” – you end up resorting to simple numerical sequences such as “12345” or noting down important passwords on Post-it notes on your computer monitor. The long-term con­sequences are not only a lack of pro­ductiv­ity, but also a lack of data security. The remedy: single sign-on, or SSO for short. But what exactly is single sign-on, and how secure is the popular au­then­tic­a­tion method really?

Single sign-on describes an au­then­tic­a­tion procedure in IT that basically always runs the same way:

1. A web user logs on once to their work­sta­tion.
2. They thereby gain access to all computers and services (including the cloud) for which they are locally au­thor­ised, as long as they’re at the same work­sta­tion.
3. As soon as the user logs off from their work­sta­tion, all access rights no longer apply. This happens either after a pre-defined period or when the user manually executes a single sign-out or single sign-off.

SSO is therefore an access method for multiple as­so­ci­ated but in­de­pend­ent ap­plic­a­tions, in which the user only has to log on once instead of entering his access data in­di­vidu­ally for each software. Due to their user-friend­li­ness, single sign-on pro­ced­ures are used both in the private sector (web ap­plic­a­tions and private clouds), and in the pro­fes­sion­al sector (ap­plic­a­tions and portals used within the company in the intranet).

If a web user wants to log in to several services and ap­plic­a­tions during a session, they usually have to enter their access data sep­ar­ately for each of them. If, instead, the user has re­gistered using a single sign-on service, this task is performed by an upstream software package. This software has all the user's access data at its disposal and verifies it fully auto­mat­ic­ally against all other services without any in­ter­ven­tion on the part of the user. A single, over­arch­ing identity of the user (similar to a VIP badge) is used, which is known to all par­ti­cip­at­ing ap­plic­a­tions and is regarded as trust­worthy thanks to the repu­ta­tion of the single sign-on service.

Various au­then­tic­a­tion and au­thor­isa­tion systems are used to ensure that such a single sign-on procedure functions smoothly.

Unlike OpenID, OAuth2 is an au­thor­isa­tion tool rather than an au­then­tic­a­tion tool. The main dif­fer­ence is that instead of proving your au­then­ti­city, you have to delegate this to a so-called client that logs on to the web page with a token from the identity provider. The advantage of this is that you don’t have to transfer data to the re­spect­ive website.

The ap­pro­pri­ate metaphor for this would be “house sitting”: If a house owner (as a user) hands over their house key to a friend (the client), the friend is “au­thor­ised” to enter the house (the website). OAuth2 is used, for example, when you want to import friends from your Facebook account into another service without passing on your Facebook in­form­a­tion to that service.

SAML is the oldest of the three systems mentioned and serves as an open standard for both au­then­tic­a­tion and au­thor­isa­tion in an SSO procedure. Here, too, a dis­tinc­tion is made between three main parties: the user (called principal), the website (called service provider) and the identity provider who carries out the veri­fic­a­tion. The process is very similar to that of OpenID, which is why the cor­res­pond­ing passport metaphor is also ap­plic­able here.

However, SAML's website always makes an active iden­ti­fic­a­tion request itself, which is sent to the identity provider in the form of an XML message, giving details of the in­form­a­tion required. The identity provider then responds with a so-called assertion, which contains the requested au­then­tic­a­tion and au­thor­isa­tion in­form­a­tion as well as specific at­trib­utes such as the user’s e-mail addresses and telephone numbers. SAML can so also be described as the issuance of personal gov­ern­ment documents at the request of the target country.

There are three main ap­proaches to im­ple­ment­ing SSO processes in common IT practices:

As the name implies, the user logs on to this SSO solution at a portal – a system in which various ap­plic­a­tions, processes, and services are in­teg­rated. After suc­cess­ful au­then­tic­a­tion, this system provides the user with a blanket iden­ti­fic­a­tion feature (such as a cookie) that gives them access to all the functions in­teg­rated into the portal. A good example of this is a Google account: Once re­gistered and logged in, you also have immediate access to other services of the whole Google group, such as the Play Store or Google Mail.

The meaning of ticketing is already in the name: At the heart of this SSO solution is a network of known services. If the user logs on to one of these services, a virtual ticket is assigned to him for iden­ti­fic­a­tion with all other par­ti­cipants from this “circle of trusted persons.” Examples include the Kerberos au­then­tic­a­tion service and the Liberty Alliance project.

With SSO, you can access multiple services and ap­plic­a­tions without having to sign up for each one in­di­vidu­ally.

For users, the main advantage is that they no longer have to remember dozens of passwords. This even frees the user from having to manage passwords, which is why single sign-on pro­ced­ures are also regarded as an al­tern­at­ive to password managers. Seeing as this is such a con­veni­ent al­tern­at­ive, and because it saves time and hassle, SSO solutions are used in private as well as in pro­fes­sion­al contexts.

Companies that implement SSO in their op­er­a­tions expect more pro­ductiv­ity from their employees and fewer helpdesk calls due to forgotten passwords. IT therefore has less work and costs less. At the same time, it makes it easier for IT spe­cial­ists to assign accounts to new employees or delete the accesses of former employees.

In addition, SSO solutions offer ad­vant­ages for internal company data security. If employees only have to remember one password, it can be much more complex. In this way typical errors in password selection, which are often the reason for suc­cess­ful hacking attacks, can be avoided. The password only needs to be entered at a single interface, and this reduces the potential for phishing and man-in-the-browser attacks. Under these cir­cum­stances, the company can afford to focus all security efforts – such as SSL cer­ti­fic­ates in one area.

On the other hand, there is a certain im­ple­ment­a­tion effort as well as the inherent weak­nesses of single sign-on. In essence, only those services that are supported by the re­spect­ive SSO system can be used. If the SSO system fails, access to the as­so­ci­ated ap­plic­a­tions will be limited or im­possible. This is the case, for example, when social media accounts are also in­teg­rated that are blocked by the network in libraries and edu­ca­tion­al in­sti­tu­tions, for pro­duc­tion reasons at certain work­places, or in countries with active cen­sor­ship (e.g. the People's Republic of China).

The actual security of single sign-on should also be con­sidered. If a user leaves their work­sta­tion, a third party could the­or­et­ic­ally use the time until the automatic “single sign-out” takes place, in order to take advantage of the access granted through the sign on. It is also prob­lem­at­ic if the “master password” for the SSO interface falls into the wrong hands – this gives the attacker immediate access to all as­so­ci­ated services.

There are also concerns due to the GDPR, in which the re­quire­ments for pro­tect­ing personal data have been tightened through­out Europe since 25th May 2018. It is now necessary to obtain an explicit agreement from the users to be able to use single sign-on. In the past, this agreement was also required, but the leg­al­it­ies sur­round­ing the situation have been changed so much that the situation is now much stricter.

In view of these potential risks, it is necessary to pay special attention to the security of the data stored on the server side. It makes sense to up the security of SSO features using two-factor au­then­tic­a­tion, or other solutions such as smart cards or tokens, which can generate TANs.

The ad­vant­ages and dis­ad­vant­ages of single sign-on can be il­lus­trated with Facebook. The social media platform enables a user to use their Facebook account to register and log on to other websites. A so-called social plug-in in the form of a “Log in with Facebook” button is in­teg­rated on the re­spect­ive re­gis­tra­tion or login page. This is con­veni­ent for the user, but it also has the dis­ad­vant­age that the more services and ap­plic­a­tions are linked to the Facebook account in this way, the more personal data Facebook collects. One single suc­cess­ful cy­ber­at­tack is then suf­fi­cient to access all personal data.

Facebook has also passed on data to these services that was actually intended ex­clus­ively for the social media platform. This includes public data such as the name and profile picture, but it also has passed on non-public data such as a person's age, place of residence, and re­la­tion­ship status. Although Facebook com­mu­nic­ates its data for­ward­ing policy as trans­par­ently as possible, in order to use certain services, users often have no choice but to agree to this data exchange. Facebook also receives data from the linked services. With these, the platform can further sup­ple­ment its user profiles and place even more targeted, per­son­al­ised ad­vert­ising.

The new SSO identity provider is to offer a higher level of data pro­tec­tion and trans­par­ency, and is to be used in the long term also for banking and ad­min­is­tra­tion. The basis for this is the data pro­tec­tion reg­u­la­tion as well as the encoded storage of personal data in ex­clus­ively European computer centres. The extent to which the project will continue depends, however, on how many partners will integrate it into websites and apps in the future.

If one re­searches single sign-on on the internet, one finds re­l­at­ively little negative in­form­a­tion about the con­veni­ent multi-au­then­tic­a­tion procedure. Instead, for years it has been treated as a downright rev­el­a­tion for the digital workplace as far as comfort and data security are concerned. The US-American Cloud Access Security Broker (CASB) Bitglass praises the global use of cloud services in companies, but at the same time cri­ti­cises the com­par­at­ively low use of single sign-on methods. This article states that the use of un­in­ten­tion­ally competing access solutions to services and ap­plic­a­tions does not make it possible to fully make use of the potential of di­git­isa­tion.

However, there is another side to the coin. As we have mentioned, single sign-on is a con­veni­ent solution for both private and public usage. However, there are some security risks involved. For example, if the master password is leaked, or given to the wrong person, all data secured by this solution is at risk. Fur­ther­more, using a physical solution, such as a USB token, has the risk that if an employee loses it, it could fall into the wrong hands.