What Is Federation Identity Management?

We also look at federated identity management, and this is related to single sign-on, but is subtly different from single sign-on. Again, we’re using a single credential here across multiple systems. Usually, with federated identity management, we’re talking across multiple security domains. It’s an enabler of access, and it can allow the automated provisioning for local and remote systems. Most implementations offer identity lifecycle management and are also single sign-on. The line between single sign-on and federated identity management blurs. And it used to be that they were very discrete. With some of the newer technologies, like SAML, we see, increasingly, people mixing these terms. So, again, with this we want to consider the identity and log-on, the account being provisioned, the account being federated.

What about the granular permissions within the applications? Again, as with SSO, they still need defining. And, again, we have issues, potentially, where we have low-security interfaces, those basic authentication-type pop-ups. Again, with considerations, we want to consider we’re trusting another system in the management of credentials. So we need to make sure it’s appropriate. What system are we trusting? And, ergo, who are we trusting with our identity, with our authentication, with our authorization processes? This one system can track and monitor the use of an identity, so a very powerful role within the organization. Also, where technologies like OAuth are used, where the authentication process is backed off to an external third party, like Google or Facebook.

And we’ve seen in the news the potential for misuse of some of those services with the scandals in April- May of 2018 around Facebook and Cambridge Analytica. Are we going to use our own identity provision? Or are we using a third-party identity provision? If we’re using a third party, it’s likely to be, likely to be a cloud based IdP. And, again, we have the issues that can arise from that. Again, we need to make sure we’ve got an appropriate network architecture that supports this. So, for both identity federation and single sign-on, these considerations are very, very similar.

The identity federation overview, here we see the directory service as the centre with cloud services, HR systems, phone books, application servers, CRM services, just some example services. What’s important is that, if we’re using this federated approach, that we understand the business logic between these different systems. If a user updates their telephone number via the internet phone book, but, also, in the HR system with a different number, which of those is going to win out? Which of those systems has primacy for that information? Which direction should the information flow go? Ideally, each attribute should be updatable by a single system. So, if we’re updating telephone numbers, it’s updated by the phone book or by the HR system.

Or the phone book passes it to the HR system, and the HR system provides the updates. This sounds really legalistic, slightly pedantic, but it’s important. We can end up with corrupt information if we’re not careful. So we need to be, it’s critical that we understand the business logic underpinning the federation of these systems.

And not all of these will be an any-to-any relationship. Changes from one system impacting the others or two changes to the same field creating a conflict, we need to make sure this design matches our requirements appropriately. Good design helps to eliminate the problems and can help us become more efficient in terms of the way we work as well. So the advantages of federation, again, similar to SSO, many of the advantages apply to federation here too. Cost for the administrator, lots of savings are potential because we’re managing a single set of credentials. We can focus on managing that single identity far more effectively.

And so we can have, potentially, a refined, better managed joiner, mover, leaver set of processes and audit processes. We can extend the seamless provisioning to third-party systems and services and extending services to customers and suppliers. The customer experience of single sign-on or federated services can be very powerful. So, things like Office 365 where we don’t have to, if we logged onto our laptop in the morning, and we access a cloud-based solution, we’re automatically logged in, very, very powerful. Also, policy enforcement for things like passwords and lockouts, again, we have the benefit of using a single, optimized identity provider. Again, as per SSO, we have the danger related to the use of a single set of credentials.

So we need to make sure they are appropriately secured. And, again, internet-based systems, we need to think through carefully what the extended risk of third-party domains is. If we’re passing credentials to third-party domains, how much do we trust them? How much can we trust them? If we’re using a third-party IdP, again, the same questions. So who do we trust? How much do we trust them? We also have similar risks around suspension deprovisioning and the requirements for complexity, the requirements to address the complexity of the integration between different sites and services. So, if we’re using online IdPs, then we need to make sure that we have appropriate resilience in accessing them.

So, if local systems are operational, we need to make sure that that doesn’t inhibit access if the IdP remotely goes down. Single sign-on and federated identity management, similar aspects to both, both require privilege management. What can you access now that the systems are connected in some way? Both require integration and the consideration and review of a proposed integration technology. And both are very powerful. And that power cuts both ways. They can be hugely powerful if we use them well and implement them well, but they can be disastrous if we don’t protect the credentials or there are weak interfaces. So federated identity management can result, naturally, in single sign-on.

For single sign-on to work, some local identity matching with privilege definitions is also required. Both need us to think through very carefully what we’re doing and how this will work practically, and how this will be managed operationally.

We need to consider our architecture locally and remotely. The latency around the synchronization of account services, passwords, and details, again, for deprovisioning. This can be a security risk if we’re not addressing this quickly enough. Commonly, the federation of identity for third-party systems is an overnight batch process. It depends on how the integration with the IdP works. It can be a live API, or it can be the federation, the provisioning of a remote account overnight through some kind of script. The deprovisioning, if the provisioning is overnight, almost certainly, the deprovisioning is managed in a similar way. Is that quickly enough if we have a suspension of a member of staff? Probably not, we may want some manual processes to supplement them.

Data quality is important for single sign-on, especially, for federated identity management. If we’re looking at the matching of different profiles, we need to make sure we have a surefire way of matching those profiles up. So, whether, this is an account name, whether this a unique ID, we need some kind of primary key that can be used as a foreign key when we’re hooking these systems up together.