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:
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.
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”.
Sign up to get the latest on sales, new releases and more …
Subscribe to our newsletter and always be the first to hear about what is happening.
© 2022 MC Press Bookstore.