- By Jesse Erdmann

Last month, Jesse Erdmann, CISSP, introduced the concept of Federated Identity Management (FIM) and this month we will describe the details behind how it works. Public Key Infrastructure (PKI) is a central concept in FIM, specifically digital signatures. For more information on these concepts please review a resource like Wikipedia’s PKI page.

While there are many ways to establish a federation, for the sake of simplicity, the method described below refers to the software and standards used by MEDNET for simplicities sake. This description will cover most FIM models, but some of the terminology may not be immediately recognizable between implementations.

The first step is for two or more organizations to agree to establish a federation, and determining what information needs to be shared. Each organization will need at least one identity provider and at least one service provider. The two organizations will also need at least one discovery service. The two organizations exchange public keys, the names of their identity providers, and the user information to be shared (which can be determined in the agreement). In general, most will simply need a list of valid roles and a description of what that role means within the home organization.

The organizations then need to configure service provider(s) to accept user information from the other organization’s identity provider(s), direct unauthenticated users to the discovery service and determine what access is to be granted to users with each role from other organizations. The discovery service(s) also need to be configured with the information about the identity providers.

When an unauthenticated user tries to access a federated service, the service provider will redirect the user to the discover service. The discover service presents the user with the configured list of identity providers. The user selects their home organization’s identity provider. For example, if a web site accepts Facebook, OpenID and Google users, the user would be presented with these three options and possibly a fourth belonging to the organization itself. The user then chooses which account they want to sign in with.

Once the user chooses an identity provider, the identity provider asks them to log in. As mentioned in last months article, there should be a strong preference if not a requirement for each user to be issued their own cryptographic key pair. After the user successfully authenticates to their identity provider at their home organization, the identity provider digitally signs the users’ credentials, for instance their username and role(s), to send to the originating service provider.

As the user returns to the service they were originally seeking, the service provider now knows whom the user is, which organization they are from and any other information provided by the identity provider including how the user was authenticated. If necessary, the service provider can alter the information from the identity provider to meet the needs of the service. The service itself then can determine what level of access to allow the user. For instance, a doctor from within the same organization as the service might be able to search broadly and edit information whereas a doctor from outside might only be able to do very narrow searches and read only a limited set of information.

FIM is a powerful tool that can be customized quite a lot to fit the needs of a federation, but the less customization required the easier the federation is to expand and potentially interoperate with other federations. The focus of setting up a federation is on the operational needs of the participating organizations. The organizations don’t need to exchange a full list of users or set up accounts for users in other organizations. The only information that might need to be updated on an ongoing basis is certificates for identity providers as they expire, new identity providers and any information like roles that the organizations agree to exchange about users. Balancing between thoroughness and ease of administration is key. The recommendation is that role information should be enough.