Federated Authentication – there is no Plan B

0 Comments

There are still a sizable number of businesses that have no federated authentication infrastructure. It is remarkable that this is the case.

There are two major reasons why federation is a necessity:

• Organizations are increasingly wanting to give external persons access to their protected resources. Companies need to collaborate with their business partners and let them access information that will allow them to better perform their jobs. For instance, if your company requires a supply of raw materials, and it’s important that you never run out, then it’s good practice to provide the supplier access to inventory levels so that they can plan shipments to meet your requirements.

Governments too require federation. It’s often the case that government services are not provided by government staff; there’s a high reliance on external “agency” personnel to provide citizen-facing services. This means that personnel from service organizations must be given access to protected government information.

• Companies are increasingly adopting SaaS applications. As more in-the-cloud applications are used by businesses there is a need to control access to corporate information held on external networks. This means that access to identity data to allow authentication of company personnel is required. Unfortunately many SaaS applications require identity data to be synchronised from the company’s Active Directory to the application provider’s data store. While this might be OK for one application, as SaaS apps proliferate it is untenable.

The preferred solution is to allow the SaaS app to “federate” its authentication service to the company’s identity provider service, which means exposing an appropriate interface for SaaS apps to use.

For the first scenario organizations will often create accounts in their identity data repository to allow an external party to access their infrastructure. This is not a good idea. Firstly it requires the organization to dedicate resources to add account details for external personnel, this means that time and effort must be expended to communicate the identity credentials for persons to be added to the directory and often a generic account is set up with the access details communicated to the supplier, no longer controlled by the organisation itself. Multiple instances of data breaches exist that resulted from compromise of generic accounts. Secondly, access rights for external personnel are quite different than those for internal staff and are easier to control if access is coming via a specifically deployed interface.

One issue that’s often glossed-over is the need for the target organization to evaluate the registration process used by the supplier organisation. If the identity checks are not sufficiently robust for the access being granted, the organization may need another form of authentication. In other words, the authentication assurance level of the application being accessed must align with the assurance level of the registration process being employed.

In the second scenario it is important that an appropriate protocol is selected for communication between the SaaS app and the company’s identity provider service. It is not appropriate to expose an LDAP interface to a cloud app; some form of cross-boundary protocol such as SAML should be employed.

There are so many benefits to federated authentication that it’s no longer a question of “if” but “when” federation infrastructure will be put in place. It is important that organisations plan this properly and take a strategic approach to adding this facility to their identity management environment. This has ramifications for business units engaging with SaaS application vendors; suppliers unable to adhere to the organization’s federation architecture should be “passed over”.

This series of blogs looks at the major components of identity and access management to encourage discussion and raise awareness.

Also in MC Press Articles