Federation is a technology that can benefit both users and companies. Federation improves customer experience, facilitates registration (conversion) and enables online business ecosystems.

Digital identities live in domains. A domain has an owner, usually a business / company. In a domain identities are born, they have a lifespan and then they (hopefully) die. In many cases the owner lets you create your own identity within the domain as they don’t know you, yet. Facebook is the biggest domain with close to 2 billion identities. Another domain could be your bank. Yet another domain would be the company you work for / own. The world is full of identity domains. Each domain has a different view of you. To put simply a domain is an organization that has issued you a digital identity and has recorded some of your attributes to their databases. The company might have one or more online services spanning different business units or even verticals.

Each domain is protected. The walls surround the domain and you access the domain only through a gate where you have to divulge a secret to the guardian. The most common secret is the password. Some domains are better protected and a password will be insufficient. You have to show the guardian that you possess a token or that you have a unique biological trait [check out our blog: What is Multi-Factor Authentication]. What’s important to realize that in most cases the access to domain A will not automatically grant you access to domain B.

Federation is about free movement between connected domains and trust. Let’s dissect that one and what it means to your customers.

Free Movement

The basic idea of federation is to allow a user to access a domain with an identity issued by another domain (company / organization). A federated user gains access to the online service with an identity issued by a third party. This third party can be a business partner, an identity provider such as your mobile network operator, bank or the government. If the federation works as advertised the customers will enjoy a seamless journey from one service to another even if they are from different domains (companies).

In consumer business federation can create business ecosystems where different companies with complementary businesses can link up. The end users will move to business partner services through links or they carry the identity information with them when they type the web site address of a business partner.

In a B2B world federation means Single Sign-On [check out What’s Single Sign-On] from the users own company network to the target network. The target network could be a SaaS service, business partner, provider or vendor etc. It will eradicate one of the most annoying customer experience obstacles in online B2B – the need to remember those 20+ passwords for each external service the employees have to remember, or the one password that’s reused across 20+ services. This will also create sigh of happiness from your customer service desk or IT operations as they no longer have to constantly reset the passwords or ask their own customers to create a stronger one.

Connected Domains

Technology such as Ubisecure Identity Platform enables connections between domains. In most cases you need such a product to transfer identity information from one domain to another. There are several different protocols that facilitate federation between domains. The old geezers like SAML and WS-Federation work differently compared to the new kids on the block (OpenID Connect, OAuth or Mobile Connect). On top of these standard protocols there are a bunch of proprietary protocols that allow online services to use e.g. bank issued identities for authentication. Federation happens if an online service is relying on a third party identity provider for authentication.

There are a few cases where e.g. company employee can Single Sign-On from their corporate network to an external service without having an Identity Provider in place. Our Identity Server e.g. includes an optional component that implements Windows Integrated Authentication. What that means that the employee logged into their corporate (Windows) network can SSO to an external service – provided he has the correct attribute set in the corporate Active Directory.

Trust

Federation is about trust. When a domain accepts identity data from an external domain, it has created a trust relationship with the external domain. At this point the trust relationship is a one way street. If both domains trust each other, the trust relationship becomes bi-directional. Trust relationships can create a mesh network, or you can have a central hub that is trusted by each participant. In the world of federation trust also equates to an agreement between the parties.

Trust doesn’t have to be absolute. The sending party can (and should) send only the minimum identity attribute set to the receiving domain. The receiving party can then treat the data as-is or transform and enrich it to better suit their own environment. The Identity Provider such as Ubisecure Identity Platform can do both tasks, helping your organization to e.g. comply with privacy legislation such as GDPR [check out our blog or slides on GDPR].

Level of Assurance is one part of the trust relationship. How and with which method the end user was authenticated in the originating domain is important information for the receiving domain. Facebook identities have a very low level of assurance compared to e.g. government issued digital identities – not many governments will issue a digital identity for Donald Duck. If the user was authenticated using e.g. a social media identity and tries to access a confidential resource in the receiving domain, step-up authentication should take place as the level of assurance requirement do not match.

Linking and Consent

A good practise, and part of e.g. GDPR is informing the user when he’s about to move to another domain, is to collect consent for the identity attributes that are about to be transferred to the receiving domain.

An important part of federation is account linking. If the user has accounts in the originating and receiving domain, this information is typically linked upon first federation. The user is asked to login with the credentials of the receiving domain, and then the sending domain data is linked to the data in the receiving domain. This action should be done with the users consent as the consent is an approval from the user that the data can be linked in the first place. The next time (and until the user revokes the consent) federation happens in a Single Sign-On fashion.

If the user does not have an account in the receiving domain, the registration process can be streamlined by using the data received through the federation event. Optimally the registration can be fully automated – except gathering the consent from the user.

 

This is only an introduction to federation. Contact Us to discuss how we can help you benefit from federation.