Sunday, April 04, 2004

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.

No comments: