The Leading Educational Resource for IT Professionals

Federated Authentication – there is no Plan B

by Graham Williamson June 05, 2017 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.

Graham Williamson is the author of “Identity Management: A Business Perspective”.


Graham Williamson
Graham Williamson

Author

Graham Williamson is an identity management consultant in Brisbane, Australia. He has 27 years of experience in the IT industry, with expertise in identity management, electronic directories, public key infrastructure, smart card technology, and enterprise architecture. He is a coauthor of Identity Management: A Primer (MC Press, 2009).



Also in MC Press Articles

Customer (Citizen) Identity and Access Management

by Graham Williamson June 13, 2017 0 Comments

As a major trend in the IDM sector, consumerization has become easier and exponentially more important. Digital transformation will literally put a significant segment of the SME market out of business and propel a significant number of SMEs to new levels of prosperity.

Continue Reading →

Access Control – RBAC & ABAC

by Graham Williamson May 04, 2017 0 Comments

Access Control is the core of the identity and access management task. Once we have correctly provisioned user data into the enterprise’s identity service we need to leverage it for access control. The vast majority of organizations use role-based access control, but increasingly, access control based on attributes is gaining traction.

Continue Reading →

Identity Management Provisioning and Workflow – A core competence

by Graham Williamson April 13, 2017 0 Comments

Identity provisioning, with an approval workflow, is a core competence for CIOs yet many struggle with a confusing array of tasks that form the provisioning process within their organisations.

Continue Reading →