Understanding Single Sign On (SSO)

OK, so this moves us onto section 7 of our course where we look at single sign-on and identity federation.

Single sign-on is where we’re seeking to use a single credential to access multiple systems. This can be really helpful. How many identities, how many credentials, do we manage? How many? Identities and credentials being separate within a single identity, you may have multiple credentials. Most of us have many, many credentials, and the danger is what we tend to do, as users of these systems, is to use the same password across multiple systems, which is a weakness. If one system is compromised, then all systems become compromised. And we may not directly manage all of those systems. So a user could be using the same corporate password on a low-security external system.

Single sign-on grants us a common architecture and a way of trying to manage this. We need to understand, with a single sign-on system, if we’re going to have a user repository, where that is. What is going to be the ultimate identity provider? Usually, what we’re looking to establish as an Identity Provider, as an IdP, is a directory service, a corporate directory service. It’s not always the case. For web-based services, externally, this could be a completely different product. Internally, most of us use that directory service. We want to examine which applications we have that support single sign-on. Typically, we require some kind of support from the application to manage the SSO process, the single sign-On process.

We also want to consider the use of the identity during the log-on process. Where does this reside? How do we manage it? How do we create it? And, if we have any low-security interfaces, then, perhaps, we don’t extend our single sign-on solution out to them. Or, ideally, we replace them or upgrade them to make sure that they are secure. So not every system will be able to support single sign-on. Where there’s an API, an Application Programme Interface, or where there’s a pre-built connector for single sign-on, and most modern applications will support one or the other, then we can look to implement single sign-on.

Where we have those low-security interfaces, things like basic authentication, the little pop-up for a username and a password, very easy to implement, and so you see it on a lot of internet of things devices. These are, typically, by default, they don’t offer encryption unless they run across HTTPS. If they do use HTTPS, are they using a secure implementation of HTTPS? If we implement SSO across some of these devices, they can become the weakest link in the chain for our entire chain of credentials. So, some considerations, if we’re going to trust another system, if we’re using SSO, who is, ultimately, going to be our identity provider? And who are we trusting with that?

As an identity provider, we’re trusting the application and that it is secure, and we’re also trusting the IdP process. Typically, SSO will deal with the system-level privileges. It will give you access to a system. What we need to think about, though, is the more granular permissions related to that process. How do we manage the types of access? It’s not enough to say that somebody can log in. We want to know the type of privileges associated with that account. Considerations we also need to make around privacy and tracking, if we’ve got one set of credentials used across the entire organization or across the internet for customers, what ability do we have to track them?

Are there any restrictions on what we should do, or what we could do? We also need to choose the IdP. And this may not always be a single login. So it may be a single set of credentials that can be used on each system, but it may not be that single login for us. And it depends on the type of systems and the type of integration that we are able to achieve. So a third party can be IdP with single sign-on. This introduces the idea of cloud provision. Ultimately, this increases the number of issues that can arise. We need to think about where our information is stored, what type of information we are storing.

And so it increases the need for greater levels of assurance and due diligence in this area.

So this is just an overview of the single sign-on process. Ideally, here we have login by the user logging onto the single sign-on process. And this then creates access for individual business applications, extranet services, network drives, web-based applications. So we provision the directory directly from a source, such as a HR system, and individual delegate applications are granted access via their user repositories. The identity provider is usually within a single domain, and it’s, often, our directory service, but it doesn’t have to be.

So, the advantages of a single sign-on service are we have fewer credentials to manage. We’ve talked about the processes involved in credential management and the typical cost of a service desk call being $50, US dollars. This has a cost, this has an impact. And, if we’re managing fewer credentials, perhaps, we can spend more time managing them more effectively. This is helpful. Also, if we have fewer credentials, the user is less likely to start writing those passwords down. If the user has 10 passwords that change each month, over the course of a year, they would have to remember 120 passwords. It’s just not practical for most people.

So, by having a single set of credentials, it’s more likely that the user is equipped to manage that process. So we can manage the joiner/mover/leaver process more effectively, and we can also focus our audit, therefore, more effectively as well in the areas that it’s needed. So, for the administrators, for the IT department, there’s a benefit. From an overall cost perspective, there’s a potential benefit. And, for the user, there is a benefit. We do want to consider policy enforcement. For things like passwords and lockouts, these are much more capably managed by Active Directory or by a similar directory service. So, by placing identity management within a honed directory service-type facility, if there are multiple incorrect log-ons, we get an account lockout.

A lot of individual lines of business systems may not support this level of, this level of sophistication or the forcing of password changes or of password complexity, whereas a directory service is very, very good, typically, at these kind of things. With single sign-on, we can have a faster revocation process. Although, it’s not always the case. It depends how we implement single sign-on.