Identity Federation – 10 Best Practices from a User’s perspective

Federation is a concept which deals with connection of two parties/providers (Identity Provider (IDP) and Service Provider (SP)). One vetting the credentials of the user and the other providing a service to the user depending upon the successful vetting of the credential by the first provider.  While setting up these federations, certain best practices can be followed by the two parties that would make the federation experience holistic for a user. This blog post explores and highlights these practices.

Let us start with the SP side, as this is where the user lands after a federation. The following are some of the best practices to be followed on the SP side.

  1. If the user has reached the SP for the first ever time, it will be good to make sure (with the consent of the user and with due thought to the user’s privacy), if some identifying information/data (like the immutable id, email id, etc.) of the user can be stored in the SP. This allows the user’s subsequent visits to be tied to it. This may be needed in order to ensure that the user gets a better service experience at the SP each time.  If the intention of the federation is not to expose/tailor user/usage specific sites, then this need not be followed.
  2. The SP should be able to link the user to multiple applications protected by the SP, with the identifying information from the federated transaction, preferably immediately after federation time, in order to establish continuity of services that the particular user was offered last time they logged in to the SP applications and/or tailor the application’s preferences to the federated user’s profile.
  3. Wherever possible it will be better to use local provisioning or remote provisioning of the user at the SP. Critical aspects like security, privacy organization’s policy in handling external users and their attributes dictate which type of provisioning would be best.    This provisioning process again would help speed up the user experience at the SP application and also will assist in giving a better service to the same returning user.
  4. Sending the right assertion parameters to the downstream application.

This is critical, as some of the vital information such as role information, auxiliary user attributes, preferences that the application requires need to be passed on appropriately to the application.  The application might be making important decisions based on these parameters in order to address the user’s needs correctly.

  1. Redirect to appropriate URLs at the Service Provider in both the cases of “User Success” or “User Failure” to get to those URLs. Failure could be because of the following reasons:

a) User not having the right role, privilege or permission to access the site or part of the site, as the assertion did not have them

b) User got authenticated correctly at the IDP, but IDP failed to send the right assertion to the SP

c) Failure of user disambiguation process at the SP

d) User unable to be linked to the right accounts at the SP

In each case, if the Failure URL gives an appropriate error message to the user, the user would know exactly why he could not access the resource. Ticketing software would probably help the user generate a ticket for the same and get a solution for the failed transaction from the SP.

Let us now focus on the IDP side, as this is where the user usually authenticates in order to reach an SP application in a federation.   The following are some of the best practices to be followed on the IDP side:

  1. Most important thing is for the IDP to display an error that is meaningful to the user, if and when his/her authentication fails at the IDP. This would make it easier for the user to know if it was any credential issue, network issue, domain issue or some other issue that made the authentication process fail.
  2. The IDP should mention to the user (either in their website or application) what the supported types of credentials allowed for authentication are. This could vary from userid/password to X509 Certificates, smartcards, OTPs or other hardware/software tokens.   The user interface should appropriately lead the user to the right type of authentication, using the right type of credentials, depending on the type of service he/she wishes to get from the IDP.
  3. The IDP would be able to issue assertions to the SP, that contains details like Level of assurance at which the user credential was accepted, other user attributes like role, user preferences etc., if applicable. This is other than the primary subject information that the IDP is contracted to send to the SP, during the initial metadata exchange.  These extra attributes would help the SP and its applications to tailor their user preferences.
  1. In the case of IDP supporting a particular profile and service, the IDP should support all the possible standard options/features linked with these profiles/services. Otherwise the users should be let known, what is supported.  This is to ensure that the sure users would not be misled, if they assume that all related option/features are supported.  For example:

a) If the IDP is supporting IDP-initiated Browser Post Profile, then it would be better if it supports IDP initiated Single Logout, Common Name ID Formats linked with the Browser Post Profile, Signing and Encryption of Assertions, Protocol Response in POST Formats etc.

b) if the IDP is supporting SP-initiated Browser Post Profile, then it would be better if it supports IDP or SP initiated Single Logout, Common NameID Formats, Signing and Encryption of Assertions, Protocol Response in POST Formats, Relay State, Accept AuthenRequest in GET and POST Formats, support “allow create” of new IDs if an ID is not already present for a federation transaction etc.

c) if the IDP is supporting multiple Protocols and features such as delegated authentication, redirection to other IDPs, etc., it should clearly mention the protocols and the corresponding profiles, features supported in each of the IDP supported website/application.

d) If exclusively a particular feature is not followed or supported by the IDP, it should be clearly mentioned by the IDP to its users.

All the above should be provided in laymen terms, so that the user can understand what features are supported and what are not.

  1. IDP should clearly mention the conditions associated with privacy clause/rules/protection with respect to user credentials/identities and their secure transport. This is to keep the user informed about how their credentials will be used. It also highlights the protection measures followed to make the federated transaction secure.

 

Author Bio:
Raj Srinivas, the author of this blog is an IAM and Security Architect with 8K Miles.   His passion includes analyzing problems that enterprises have in the IAM & Cloud Security domain, from various verticals that include Banking, Insurance, HealthCare, Government, Finance & Mortgage and provide in-depth solutions that will have far-reaching effects for the enterprise.