FIM(Federated Identity Management) based Security Services

After writing a previous post and discussing that FIM is really far away, I read a good article on Digital ID world on FIM which really forced me to think how this game may play out over time.

What is FIM?

From my point of view it is a use case, in real world, of the basic idea that user should not be bothered to login by each and every resource they want to accessed(SSO). So once user has authenticated with one resource manager or standalone authentication product, all the other resource manager(lets call them trusting party) that TRUST the particular resource manager or standalone product(lets call it trusted party) will accept the identity provided by the trusted party. We have here three participants i.e. user, trusted party and trusting party. Does not that remind you of PKI? Well may be not but it does to me and so let me pickup that thread of thought.

PKI vs FIM or why FIM may succeed where PKI failed? Lets try to dissect the PKI failure. Some of the possible reasons may have been

• immature technology vendors and their products(this may have been more of a chicken and egg situation)
• high distribution and maintainance costs for retail customers
• pre-911/Slammer easy-going attitude on security
• secure delivery and Storage of private key(whether browser or smart card)
• privacy issue on customer side
• Global registry of trusted CAs, complex revocation procedure
• CA's inability to take up the Liability on the identity of sender esp. in international systems in open PKI.
• business requirement and technology are inseparable i.e. Public Key and private key have to be used for the SSO infrastructure to work.

Even though the list above may not be the complete and some of them were addressed to a degree by maturity in the PKI on business side. This has provided FIM a better chance to survive since people do not have to learn the lessons as in case of PKI (or may be we will not learn!!). Now let us see some of ways in which FIM is different from the PKI

• Duration of trust: An important issue with the PKI is that the duration for which the trusting party is ready to accept the user is defined by the duration for which the certificate is valid(unless the CRL infrastructure is in place which kind of provides a Go No-go feature). Incase of FIM the duration of trust can be configured and limited during the initial sign-on which should be helpful in developing policies for integrated re-authentications, quality of service requirements and may be other great uses.
• Degree of trust: The PKI was so much dependent on key architecture, it was impossible for other authentication strategy to survive, which pissed a lot of people who did not want to establish a PKI for a simple website. The FIM does not set any such requirements on authentication and demarks the authentication and trust establishment as two separate domain controlled by their own rules. This implies that the trusted party and user can decide what type of authentication they would like to have and at the same time it allows trusted party and trusting party to come to agreement on authentication mechanism- level of thrust mapping. For example password based authentication may map to lowest level of trust and SecurID may map to highest level of trust in case of email website, while securID may map to lowest level of trust and fingerprint scan may map to highest level of requirement for a corporate financial transaction.
• Privacy: An important issue with certificates is that it binds person with the certificate and people have to develop the policies around it to address the intent or use of the certificate. Some of these were solved by adding more information to certificates like usage policy but this lead to all or nothing i.e. user had to provide all the information or no information to sites. FIM addresses these basic issues by providing ways to tie together multiple identities, user's role information and additional information specific to user on a per-trusted party basis instead of all-or-nothing case of PKI. The support of roles allow implementing delegation which was not possible without multiplying the number of certificates client had to manage in case of PKI.
• Competitive MarketThe biggest hinderance to PKI was that vendors were banking that they would be global directory for certificates and that lead them to push for open pki. At the same time the browser's PKI component implementations required that a seamless integration was available only to selected few whose CA certificate could make to the browser. Similar idea of one or two very large trusted party in the field of FIM has also not taken off in big way. This is where the WS-Federation and Libery Alliance have advantage. These specifications allows development of closed FIM communities(their PKI equivalence have been more successful) where the trusted party become the pivot which can brings together users and trusting parties. This to some extent opens the market to competition and allow trusted parties to compete for trusted party and users which may be benificial to the market as a whole. It would be interesting to see whether existing branded portals and e-commerce sites (or similar large repository of user identities) jump onto this bandwagon to generate additional revenue in a role similar to that of banks in Credit Card business.

Components of FIM Basically most of these components are addressed by specifications, but at the same time they are not completely defined by such specification.

• Trust/Liability/Contracts on paper and its enforcement in implementation Basically trust forms the major part of any FIM. This can be achieved technologically and liability arising from its violation is limited/transfered by contracts and insurance. So, it is important to decide on the security used for transport of information(asymmetric key based, shared-secret based, hybrid or leased/secure lines), system that is producer and consumer of information( security policies for these components should be agreed upon and if required mapped to companies security policy), system that store the information and at the same time set policies and checks to control the damage.
• Authentication Modules This is a component is present on trusted party system. The user connects to trusted party (either by redirection when user tries to access resource or directly) and uses one of the authentication process (like form-based, basic authentication, SPNEGO, SecurID, fingerprint scanner) to send the authentication information to trusted party. If the authentication is successful, the trusted party starts a tracking system/session for the user and generates a token for the duration of session with application specific user information (it almost looks like we are talking kerberos now). The user can be then be redirected back to resource with token in variety of ways(see SAML for more information about supported protocols). The information provided by token helps resource manager to setup an session for user with associated information about its role, relevant attributes like preferences. Additional management information (like session life-time, authentication level, account status, session tracking ID) may be passed by trusted to trusting system (NEED TO FIND how that fits into Liberty/SAML). Rest of the policy information like what the user/its role has access to would typically be managed by trusting party, but in some cases this information may be passed by trusted party to trusting party during initial-SignOn.
• Identity ManagementThe trusted party is expected to have an identity management system in place and it will have to be integrated with identity system on trusting party side. This is required to manage creation of the user id and management of its attributes, password(reset), trusting party service (self-)registration. The identity mapping information would be pushed to trusting party at runtime or out-of band, and may have associated workflow that requires input and validations from all the parties(SPML is good candidate for such requirements). Another important part is flow of identity information from trusted party to trusting party and from users to trusting party. A lot of time the trusting party may have additional or existing source of identities which may need to be made available to trusted party so that users can use the information to tie together all their identities or there might be financial account information which user may not want to leave with trusted party(well it is not trusted that much ;) ). Besides that, it is important to form policies on dealing with identity name clashes, multiple identity on trusting site for one trusted party's user identity and vise versa.
• Session Management Interface Though not part of most specifications, I think it is an important component. Defining what the session is in context of trusted party and trusting party, how can information related to user or session be propagated to all the concerned party and how the trusted party or trusting party will react to such notifications at runtime would help every body who is part of FIM community to design their system to take care of various usecases.
• Liberty Alliance/WS-Federation specification implementation Well this may be simplest part and available out of box from various vendors.
• Legacy system integration This basically will consists of those applications that can not be updated, due to various reasons, to integrate with FIM infrastructure. It may be interesting what trusted party would make available for managing such requirements.

This kind of completes the basics on FIM as a security service. I am not sure whether a complete picture has been captured....