Federated Identity Management Product or what you should remember when buying a product

It has been a long time since I last wrote something, but FIM is something that I see people doing even without realising that they are doing it. I will try to list some of the use cases (which can be mapped to concept of profiles in SAML or Liberty world) that are part of the general specifications and some that are not. This article does not provide an introduction, but you can read here to better understand what I am talking about. Just like any previous article, I would like to break down the usecases into two parts
  • Runtime These usecases typically occurs every time the user hops between sites that are part of a federation(that has such a star-trek era feel to it). This typically deals with how the information is passed from one site to another site when the user is doing site hoping resulting in session establishment. Besides that it would also include auditing all these events for monitoring and reporting purpose.
  • Management These usecases basically talk about the management aspect of the FIM and typically would occur out-of-band/first time user accesses the new site/last time user accesses one of the site. This deals with the idea of token transfer protocol (including trust establishment between sites), the identity mapping between two sites and other configuration like authentication level mapping. These management events must be audited to ensure that all the changes can be tracked and used for policy enforcement validation.

Runtime

The FIM can be applied to a different categories of applications the most important of which are as follows
  • Web Based cross domain Single Sign On
  • Web Service Authentication
  • Client-Server or distributed applications with properietory protocols.
Rest of the article will discuss FIM as it applies to Web Based application with Cross Domain Single Sign On requirements. The basic use case can be defined as follows
  1. User access site1.com and authenticates at site 1 using specific authentication method which sets up the context for the user(here after referred to as session)
  2. User then clicks on specially formatted URL which generates a token and then redirects User to site2.com(via GET or POST)
  3. On the Site 2, if token is not received via redirect, it is retrieved from Site 1 by Site 2. This token is then validated with regards to whether it is from site 1
  4. After the token has been validated to be from site 1, the user information provided by site 1 must be mapped to site 2 and a context(session) would be setup with the information passed from site 1.
  5. After the user has completed the work he would logout from Site 1 and which time the site 2 would be required to logout the user.

Management

The basic idea about the management is of identity federation and trust setup. Trust setup would typically be performed out-of-band. The identity federation or mapping the identities between two sites, can happen out-of-band or during the first visit to federated site. At the same time identity federation should also address the requirement to break the the identity mapping. These management setup may be performed as self-service or by administrator of two sites.

Components

Most of the FIM systems would consists of the following components as introduced here.
  • TRUST: The basis of all the FIM is trust. Besides the legal aspect of it, the technological aspect of trust can be established in variety of ways. Some of the simple ways to setup trust are
    1. Shared Secret between sites
    2. Public-Private Key pair and/or Mutually authenticated SSL between sites
    3. User's IP address range(if site is being accessed from intranet for example) for access
    4. contact Site's IP address range
    5. ID/Password pair
    Besides that the ideas are around with regards to third party Trust parties, trust brokering services and so on. I donot expect to see them in the market as requirement in near future.
  • Identity and attribute Mapping The identity from site A must be mapped to identity from site B at runtime. This mapping can be
    1. One to One between the two sites
    2. One to Many incase when the same user from one site may be administrator(for the company) and user of the other site.
    3. Many to one incase the set of employees are given access to a paid site through a standard account id.
    Besides the identity itself, the token can have additional information like user's attributes(like address, etc) and group/roles(at site A or site B). This information would be used by the destination site to build the context for the user. At the same time, the destination site can have it's own set of information about the mapped identity and may be added to the context for the user. With the concept of mapping and aggregating user information the following must be considered
    • Whether site 1 information over-rides the site 2 information or the otherway.
    • Incase of multiple identity matching how is identity selected (may be using simple rule like which domain name is being used or what is IP addresses of client to access web site. It may alternately provide identity choice to user)
  • Session Management Although session management has not been seen important from the point of view of standards, I think this is somthing that would be important in the wild. Some of the issues that would have to be addressed in the process would be as follows
    • Session Timeout: This is about how the session timeout would be set for the federated site. Would that be based on the timeout of main site or decided by destination site.
    • Session Logout: Even though the concept of universal timeout has been made part of the SAML 2.0, it does not addresses how the sites would manage concept of site specific logouts. This may be important from the point of view of Quality Of Service and service metering.
  • Authentication Module Even though the authentication is not part of FIM per se, the authentication mode is used by most sites to setup the access control form user. For example, the user may have been authenticated using basic Id/Pwd at the site 1 and then needs to access some information with higher authentication requirement. In such step-up authentication requirements the federated site may ask user to perform step-up authentication at site 2 or redirect user to site 1 for step-up authentication or may be just display access denied. In a large federation it would be important to decide whether the point of entry authentication be a specific site or would all the sites allow authentication using same information(i.e. ID password combination) and then allow the user to SSO to any other site that are part of federation. These issues also come into play in case of bookmarks(Passive Requestor Profile) for federated sites. When user tries to access the bookmark, the site in question may have to redirect to original site for authentication(if user is accessing particular Domain Name or URL pattern) or it may itself provide user to login into the its own site.
These requirements are some of the ideas that I think the products should provide. In next 2-3 years these use cases may appear in wild and we should be ready to solve them.

Comments

Post a Comment

Popular posts from this blog

Vendor List

Updated: November 12 2006 I am trying to come up with the list of vendors and associated products in the Identity and Access Management arena. Please note that this list is based on marketing/public information and my understanding of the terms which may not comply with any specific groups' definitions and/or requirements. This is by no means a complete list and will keep growing as I get more time to add them and find more companies (any help on that front will be really appreciated). Before we go further along, lets try to define what each of these product typically do so that my mode of classification may make sense or any flaw in my classfication will become apparant. Identity Management/User Provisioning These products typically provide the facility of Workflow-based Identity provisioning, password reset, identity reconciliation/discovery, delegated identity administration and self-service features on wide variety of identity platforms (like LDAP, Unix, Windows, Mainfra
Read more

Understanding IAM Technology: Web Single Sign On (Web SSO) Part I - Introduction and Use Case Definition

Image
Update September 6, 2015: Part II in the series is now available . Update August 19,2006: I am rewriting this entry based on the methodology I am using for some of other domains. Hopefully, the new methodology would make it more useful to some of you. I talk to a lot of people from developer background who still do not have a good background in the IAM technology. Eventhough there is a lot of information on the web, I have felt a lack of good technological discussion on the various component that  actually form the IAM domain. Some of the good sources for the information on IAM are Microsoft Identity and Access Management Series Archie Reed Oracle Federated Identity Buyers guide Oracle Identity Management Buyer's Guide Identity Management Dissected Most of these document discuss the basic concepts but do not extend it to existing technologies and how it applies to them. This series is an attempt to look at the technology behind the Identity and access manage
Read more

Reclaiming your account: Password Reset/Forgot Password

Image
This is probably one of the oldest functionality that is part of any password based system and by now I was hoping that people will have figured out most of the ways of doing it. But while reading answers on stackoverflow on this topic, I was impressed by new ways being developed and implemented by developers in wild. While reading the discussion I felt that there is lack of a structure to look and study this functionality and this post is an attempt to define a structure. Before I go there, I wanted to capture my understanding of the password reset functionality. Why - Well if we are not noting down all the accounts we have created in life (either electronically or manually), it is possible that we are going to forget passwords for some accounts as we age. Even if you follow some techniques like having standard passwords across all your accounts, due to site limitations, change in word preferences, etc, you may not remember the applicable password for a site and so the lifesaver Why
Read more