What does Single Sign On mean? Technologies of Single Sign On

Here in YGHT we try to educate and help people with their cybersecurity. One question that people ask me is What does Single Sign On mean?

In this article we are going to unravel what does Single Sign On mean.

Single Sign On (or SSO) is any technology that takes advantage of another systems login process.  It is born out of the inefficiencies that are still rife around identity management. Similarly, end-user productivity improvements for only having to log in once.

SSO is essentially the use of a single password to control access to lots of other areas. For instance, that means that if someone compromises the “master” password. It has, as a result, the compromisation of all the other services.

Technologies of Single Sign On

• Scripted
• Kerberos
• SESAME
• Perimeter based Web Portal Access
• Federated Identity Management
• Once In Unlimited Access

Scripted Single Sign On

Scripted SSO is where the actions a user would need to take are performed by an automated process.  Essentially its just sleight-of-hand on behalf of the user.  Not necessarily possible with all technologies, particularly those that use multi-factor authentication. 

Opens up many potential security problems.

Particularly where the script uses stored passwords and reversible encryption.

Kerberos

Kerberos is based on three elements; authentication, authorisation and auditing.  Kerberos in a few words is a network based authentication technology.  It uses secret key cryptography for secure authentication. 

The four basic requirements of Kerberos are; Security, Reliability, Transparency, Scalability.

KDC / KDS – Key Distribution Centre or Key Distribution Server
TGS – Ticket Granting Server
AS – Authentication Server
TGT – Ticket Granting Ticket
ST / AT – Service Tickets or Application Ticket
A principal is any system that interacts with the Kerberos server.
The end point server is the destination to which the principal wants access.

Assuming correct authentication etc, the process is as follows:

1. The principal requests authentication from the KDC
2. The AS services returns a TGT and session key
3. Using the ticket and session key the principal then asks the KDC for an ST from the TGS
4. The TGS returns the ST if the principal is allowed access
5. The principal then requests application access using the ST
6. The end point server grants access

The acronyms here are all over the place in the book.

Based around encryption

Based around encryption it suffers from the same problems.

For example, the key length is crucial.

Too short and the encryption is not strong enough. Consequently, someone can break the encryption and steal your data.

Too long and the processing overheads requires to prevent the system from performing adequately.

Ticket lifetime settings are also important to prevent authentication replay.  Physical access is as always a major problem for any computer system.  The passwords in use are still the weakest link as the tickets are based on the password.  Should be considered as a single point of failure unless the KDC is replicated or has HA.

SESAME

SESAME, aka Secure European System for Applications in a Multi-Vendor Environment.  Technically it is an extension of Kerberos. 

Its purpose is to address problems in Kerberos.

Namely scalability issues around complex encryption key management. Also, permission storage so that it doesn’t rely on the KDC as much.  SESAME also takes advantage of asymmetric encryption, presumably to make it easier to exchange symmetric encryption keys.

Perimeter Based Web Portal Access

Perimeter based Web Portal Access – envisages a proxy server onto which you authenticate.  Behind that proxy server is a number of web-based applications and services.  By the sheer fact that you are authenticated onto the proxy, you are now authenticated onto the web-based services.  The proxy determines your level of access.

Federated Identity Management

Federated Identity Management is where several organisations work together on their users identity management.  There are two models; cross-certification and third-party certification. 

Cross-certification is where the various members have a trust relationship between each other and (limited) access to each others identity management systems. Similarly, Cross-certification can authenticate users through this information. 

Drawbacks are that it does not scale well, because everyone must trust everyone. Therefore, it is limited to trusting that the various organisations perform their vetting correctly and thoroughly. The third party certification model puts all the trust in the hands of a singular third party. That is assigned the task of vetting etc. 

Scales well as the trust is only one-directional to the third party and removes the trust problem as only one party needs to do any checking and it’s their sole responsibility.

It is worth considering Once In Unlimited Access although this is not really authentication.  It is what it says on the tin…  Essentially it relies on the fact that you have access, so therefore you must be allowed.  Not really considered secure but might serve a business purpose.