There are two main drivers to identity federation:
- Validating the identities of staff before adding them as users to corporate internal systems is both laborious and costly – if you can rely in someone else to do this you can save precious resources.
- Users today already maintain their own identity provider services (Facebook, Google, Yahoo etc.) and they don’t want to keep having to register with every company they do business with.
Federated authentication means that we trust someone else’s identity validation and we agree to give access to our systems to those who have been “checked out” by a third party. This “third-party validation” can be an extremely powerful and beneficial approach to extending our business.
In any federated authentication environment there are service providers and identity providers. Service providers maintain applications that users want to access. Identity providers validate users to ensure they are who they say they are, and to put the credentials of validated users on a system accessible to the members of the federation.
Federations should be governed by a documented registration process that will identify how it validates its constituents. The federation partners must determine, and agree upon, the documentation applicants must provide when they register and level of validation required.
One of the benefits of most federations is the provision of Single Sign-on (SSO) across multiple domains. If a user has logged on within one domain they should be able to access applications in another without re-entering their log-on credentials.
Federated authentication systems are a mandatory part of any cross-boundary computer network. With the increasing migration of services to “the cloud” federated authentication is the only way for relying applications to securely authenticate users.
Federation services should use the SAML protocol for passing user credetials between identity providers to service providers.
