Skip to Content
Author's profile photo Nikola Simeonov

Implementation of Identity Federation for SAML 2.0

This blog describes the enhanced SAML 2.0 features for identity federation. It also gives a link to a Wiki page that describes the configuration of such features. The Wiki would help you with some example scenarios that show the applicability of the new features.

The identity federation provides the means to share identities between partners which are usually identity providers and service providers. However, to be able to share the identity of a user, these partners must know how to identify the user. For that purpose SAML 2.0 defines name identifier (ID) as a means of establishing a common identifier. The features that this blog characterizes relate to the configuration of identity federation for a partner that uses trusted identity provider(s). Such partner is usually a service provider.

The enhanced federation allows administrators to set three types of federation that do not depend on the selected name ID format: Persistent Users, Persistent Users (Advanced), and Virtual Users. It also allows administrators to specify what attribute of the assertion the system must use for the identification process and how to identify the user in their system. In addition, the administrators can set a filter, prefix and/or suffix to restrict the users, to use only part of the user ID, or to make the user ID unique.

More Information

User Documentation

I am glad that I already got a comment on this blog. I am looking forward to hearing from many others. Don’t forget to review the linked Wiki page. Ho do you find the scenarios there? Any feedback is appreciated.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Andy Silvey
      Andy Silvey

      Thank you Nikolai,

      this couldn't come at a better time, we have to setup a POC for this yesterday 🙂


      Author's profile photo Chandrakanth Angannagari
      Chandrakanth Angannagari

      Hi Nikola

      I refer to your recent blog about the various scenarios for configuring Identity federation

      Many thanks for putting that in details. I however had a question about the SAML concept in general and wondering if you could clear that for me

      We mention in scenario one (persistent Users) where we configure for the trusted provider with "Email type persistent". My question is , how would the IDP "know" that it has to set Email into the saml assertion because this configuration is done on the SP side?. Is it that the SP makes a SAML request to the IDP instructing it to "set" the Email into the the SAML assertion?

      Also in scenario two, we configure "department" in the Assertion based user attributes" department is part of the SAML standard? What if the IDP is not capable of doing this? Is it for this reason that it is necessary to align with the IDP admin about what the config  is being done on the SP side?