Sunday, February 29, 2004

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....

Sunday, February 22, 2004

SSO and Web Hosting companies/Telco

Over last few months, something that I have been thinking why have the hosting companies not started providing sign-on services. It is a chance for both the hosting companies to provide this important service and at the same time allow the chosen vendor to prove how well its product works. But then after some deliberation this is what came out
  1. Where is the Apache/tomcat of SSO? Well if look at most of the companies that provide very low cost hosting service(and hence have very high volume), are able to keep them low by using free software and so till an open-source stable system is available, the guys are not going to bother about this. But at the same time, the SSO vendor can do some kind of strategic partnership with a big hosting company and use their solution as a reference implementation. This is something similar to what IBM has done when it provided DB2 to am not sure about this?) and you find it in a lot of places
  2. How confident are we?: In order for that to happen, the vendor itself has to be confident about its product. Even after almost 2-3 years since some of the products came to market, some of the products have their limits when it comes to deployment capacity and stability. At the same time to be fair implementing a SSO is a complex challenge in itself and so far complete suites are not available that target hosting companies (i.e. a combination of products that will help migrating existing hosting to SSO platform).
  3. Is it worth it?: So how would a company go about hosting such a service. I guess most of companies have apache servers serving multiple domains. The SSO product would be installed on this and configured to protect specific set of domain. Then there would be directory/database that would have to be managed with so many identities and passwords. So far the identity has been distributed across different application being hosted. Now this needs to be consolidated and brought into single place. Will the existing products be able to handle the onslaught? May be.. may be not...having 15-20K is one thing and 1Million is a totally different beast. I have seen products that can take onslaughts of that order, but what is that going to add to user experience(and what kind of hardware upgrade be required) or a different architecture of distributed, indexed database may need to be developed so that smaller servers and databases can be used to attack the beast(may be vendors need to learn something from google on that ). Last but not the least a simple integration process should be available before the hosted applications can be migrated. In order to allow existing application to continue, the products should send the id and password specific to the back-end application for authentication. This automatically means the whole issue of identity and password mapping and synchronization comes in. Where will the new identities be created or where will password changes and reset be managed or which password reset system will be used(at the application user registration console or SSO registration console) and how will that be added to applications' database(this is the job for superman aka "stable metadirectory with very simple user interface for configuration" !!). Now as we go along, what are the approaches available for backend application integration. Most of the time it can be the simple header variable based integration. Given that the products need to grow inorder to make such deployments simpler, it may not be right time for implementation. The lessons learned from the Credit card processing services available for hosted application should form a very good model to decide on how the hosted applications will be comfortable with the entire process.
  4. Where do we stop?: Now what about group information, user attributes? So basically should SSO manage some or all the information. I think user identity may be first step, but ultimately all the user information may have to be migrated to SSO with generation of the credential that is sent to back end specific to the application. We have SAML in combination with 2 method(login and logout) based integrated authentication modules to thank for that(where are they?). Besides that since the information to be sent to backend have to be specific to application, the product should have a good way of managing this information on per-application basis(I have not seen very good attempts on that side).
  5. What about FIM(Federated Identity Management)?: I think that is a long way into the future. Let the corporate jump on to the band wagon and solve the trust, liability issues before hosting company should jump on this. May be the market will evolve like certificate market where a set of third-party will be trusted agent which will issue proxies(as hosted application, certificates, web service or god knows what) that will be trusted by both most of the parties and these third-parties will consolidate or trust each other over long run. Or the market will never grow beyond the one to one OR consortium based trust. But if third party companies can really take it to next level it will be good for every body.
So, these are my thoughts on the subject. Let us see how things really work out.

Saturday, February 14, 2004

Identity and Access Management - Part II - Identity Management

Before we go too far on the path to understand what its management is about, let us define what identity is.

What is Identity? (I am not Dave, that is just my Name)

Incase you read the link that I provided in Part I, you have the basic idea about how identity has been defined so far as an abstract concept. In order to map this to more real-world scenario I have interpreted the three tier system in the digital world as follows
  • Core Identity: This is the digital representation of an entity in the domain. This needs to be unique in the particular domain and can be a UUID, email-id, employee id, or something that uniquely identifies the user in the domain.
  • "Action" Identity: This defines the identities that the core identity uses to perform its work. So for example the core user can use unix root id or a NYSE trader role. These identities are representation of the core identity in specific resource(s). Typically these identities are used by the resource manager to identify the user. These identities are typically mapped to core identity(or vise versa) during provisioning.
  • "About" Identity : Every identity has some information associated with it (like name, address, and so on). This information helps the resource managers in the domain to understand the core identity better and provide the resource based on the policies defined. I like to categorize this information into the following sets.

What is identity Management?

The basic idea behind identity management is to manage the three tiers of the identities that represent the entity in the domain. The core identity is the basic representation of the entity in the domain. The resource managers (which provide the functionality and data to the entity) due to various reasons may not recognize the the entity as the core identiy but as a completely different user id (for example root id on unix) or by the role the core identity has been assigned (for example unix admin role or NYSE trader role). These identities (the "Action" identity) would help resource manager recognize the user in its context instead of bothering about the core identity. This simplifies the job of resource manager in the sense that it does not need to know core identity of each and every entity to serve the entity. Once the resource manager has recognized the core identity in its own realm, it may need additional information about the identity to make decisions based on the resource manager policies. These decision can be about whether it should give access to required resource or what resources should it serve to the entity and so on... I like to classify this "additional information" in to three types.
  1. Authentication Information - This information is needed by the authentication system of the resource itself or that trusted by resource to make sure that the entity is who it claims to be. This information can be
    • What entity knows (like password)
    • What entity has (like token generator, smart card, certificate)
    • What entity is (like finger print)
    The entity in this case can be a physical entity like user or a logical entity like an application.
  2. Domain Information - The domain specifies that each and every entity's representation has a basic set of information associated with it. This may be information like name, address and so on. The decision about what , is typically made at domain level.
  3. Resource information - This information is relevant only for particular resource only and does not make sense in case of another resource manager or will be used in different context in another resource. For example, the trade limit may make sense for an security trading application, but would not be relevant in a tax application and at the same time, may have different connotation in a forex application. This is typically defined by the resource group itself.
In the next section I will try to define what component typically come into play during the runtime i.e. when entity is interacting with resource manager to get access to resource and during management.


The Identity management system should be able to help the resource manager identifing and authenticating the entity at runtime.
The authentication mechanism can be broken down into two component -
  1. Process: This is the moving part of the system which typically performs the following functions
    • Retrieved the authentication/identification information using the configured procedure. This can be achieved by using a wide variety of ways like Basic Authentication, Forms based, fat clients, CSI-IIOP, Certificate, fingerprint scanner, IRIS scanner, Challenge Response like SPNEGO, SecurID and so on. An important part of the retrieval process is to ensure that confidentiality and integrity of the authentication information is not compromized in the process.
    • Once the information has been retrieved, this information may need to be processed using specific algorithm (like hashing algorithm for one-way password or CRL validation for certificates) before information is in the form that can be compared to information in the database corresponding to entity.
    • Besides that it validates whether the security policies regarding inactive account expiration, authentication information expiry(incase it is not biometric), number of logon trials, time and location of access by entity are being followed.
    • Eventhough not part of core authentication, process generates the authentication audit events as configured.
  2. Database/Directory: The trusted source of the authentication information with keyword being "trusted".
    • The database should be designed so that the integrity and confidentiality of the authentication information can be maintained.
    • The process uses the database to validate whether the information provided by the entity matches the information present in database. Most of the time this distinction about database being separate from process is not made. But it is important to realize that as we move toward SSO a very important strategy may comprise of having Single Database which is shared by different process which themselves are embedded in the legacy applications.
    • These databases can be LDAP based directory, Active Directory, RDBMS, file system, ACE Server database, certificate store, to name a few.
    • Once the distinction between Database and process is well understood, the next idea that should be kept in mind is how process interacts with database i.e. what are the databases that "process" supports, does the "process" provides facility to map the existing data structure/schema to its datastructure or does database schema need to be specific to the "process" being used.
Most of the times in the discussions, some thing that I have found missing is the concept of session. Basically, this is an important part of authentication and authorization but at the same time is not addressed in most of the specification. Typically it may be hard to define the concept of session, but in most of the cases the session can be defined as the duration during which the entity was interacting "actively" with the resource manager. The definition of "actively" is very subjective which may vary from few minutes for a user application's to days for long batch processing transactions. But for most of the applications, the concept of session inactivity timeout and session failover should always be kept in mind while considering the authentication which typically gets tied to session management.
Based on the components that are described above the authentication runtime implementations can be broken down into following categories.
  • standalone component like Web SSO products or Desktop authentication where the authentication of the identity can happen even without the entity connecting to resource manager. In such scenarios the resource manager trusts the authentication mechanism and uses the identity(and additional information) passed to it to construct entity's identity. Incase of the standalone component it is important to understand the mechanism and security behind the transfer of user's identity to the resource manager from authentication process. This transfer can happen via Header variables(in case of Web applications), SAML, Privilege Certificates(PAC) and so on. Besides that resource may use different identity to identify the entity, in which case the user identity mapping would had to be performed by either the authentication mechanism or the resource manager.
  • Integrated component like built-in security module where the authentication happens when user tries to access the resource by contacting the resource manager. This is the most prevelant implementation before the Single Sign On concept came into the picture. The resource manager in this case has a built-in module that provides the identification and authentication facility. In addition to that these component provide the management facility(like identity creation, password reset). It is important that these applications are part of the single point Identity management strategy. Most of the provisioning product support the concept of adapters/connectors which allow you to integrate the identity solutions into these integrated component using component specific APIs or standard protocol. Incase the database of the component is built using a standard RDBMS or Directory, Meta-Directory products are available which can synchronize the information between the products. A very important point to remember is that the identity information can flow both ways i.e. from central repository to resource manager's identity database and vise versa.
  • Shared database This catagory falls between the two approaches described above. A lot of new inhouse applications typically take this approach. It allows the authentication process to be integrated with the resource manager but uses a database that is not under complete control of resource. A good example would be Unix box using LDAP/Kerberos for authentication purpose. The process uses the available database (which may be managed via other process) for validation of authentication information.


The identity management deals with the process of addition/modification/deletion of the identities and associated information. There is nothing new with this concept, and for years the resource managers have provided built-in components that do exactly the same and enterprises have developed systems in their operations department that use workflow applications to manage this process. These systems typically work as follows
A request paper work was submitted or a ticket was create via helpdesk. The help desk/operations department used the workflow product (like REMEDY) to send the ticket to appropriate administrator. The administrator then performed the identity management operation on the application using the application's administration interface.
This approach has two things missing
  1. End-to-end automation Due to the human factor a lot of time the tracking, auditing, accountablitity is not exactly the best thing about the process. So it would really be great to have an end-to-end system that can allows tracking, auditing the complete process and give accurate status of the process. One of the ways is to automate the complete workflow and include all the entities involved in the process(users, their manager, resource owner). This is an important contribution of the latest breed of provisioning systems. This frees the administrators of the dreaded work of reseting password and concentrate on application administration.
  2. User Interaction An important part of the previous workflow systems was dependency on third-parties like help desk/ system administrator for the completion of the work. The new products bring in the concept of self-service where the user can perform the basic administration tasks like password reset, creation of accounts to some systems( once they have basic privilege) without requiring input from third parties. It is very important to design the workflow so that the confidentiation and integrity of the systems is not compromised for example the password reset workflow should be designed so that only the person who is the owner of the account is able to perform the reset(this is typically implemented in variety of ways like using known email id, personal question/answer).
Most of the client being used to concept of ticket tracking expect similar functionality from the identity management systems. Most of the old ticketing systems allowed users to provide free-text input which was meant to be for human administrators. This is I think the biggest hurdle in new systems where the complexity of the ticket that can be generated during the process is very limited and should improve over some time. Eventhough the level of functionality may vary with implementation, most of the products have the following component in some form or other as part of their implementation.
  1. Interface is, understandably, an important part of the identity management. There are two parts of the interface - input and notification. The input basically deals with interface(like web based, fat client, APIs, Web Service, SPML) using which the users and other process can interact with the identity management application to provide input required for the workflow to complete. Most of the workflow have various points at which it needs user input(like approval of a request, additional information) and at those point the IDM application needs to notify the user via different kind of interfaces (like email, lotus notes, groupware, pager, and so on). So it is very important that identity management should have an appropriate blend of the two interfaces.
  2. Delegation is an important part of the operations. This allows the help desk to manage a lot of the basic facilities and free the application administrator from it.
  3. Rule/Policy Engine Most of product support some sort of rule engine. This is important part that helps designing the rules that can be associated with input validation and choice of workflows and so on while implementing complex processes.
  4. Workflow engine This is one of the most basic thing that every identity management product that provides complete solution has. This helps the defining the business process for identity management and automate them.
  5. Trusted Repository Most of the enterprises already have a separate systems that manages the employees(HR ERP), customers (CRM) and so on. These identity must be accepted by the identity management system as trusted identity and hence the concept of trusted repository.
  6. Reconciliation/provisioning Adapters/Connectors Well these are the components that complete the automation. Basically these are the components that connect to the resource managers or its security database and add the identity information to it.
These components typically form part of the identity management systems. Next time I will try to take up the Access/Authorization Management systems.

Saturday, February 07, 2004

Identity and Access Management - Part I Introduction

What Consumer Want or Problem Definition Well sometimes even they don't know! But objectively looking at the problem definition can be stated as :
"Enterprise have a large number of resources that need to be a accessed by a large number of user. With increasing number of resources being accessed by each user and each resource being controlled and managed by business groups, the following is some of the pain each of the party is going through
  1. End User pain: the number of identity that the user need to remember to access each resource is increasing
  2. Management pain: Management does not have a clue(leave alone controlling) on what user has access to on a day to day basis and they have the auditors / compliance officers breathing down their neck.
  3. Operations pain: Operations spending more and more time in correcting the mistakes of the users(like password reset), management(get me report for user access and make sure that all the security policies are followed) and following business workflow and security policies with a possibility of making mistakes due to non-existant end to end tracking system
  4. Developer pain(or is it?): Need to write the same code for managing the user information every time a new application needs identity and access management.
  5. Resource owner's pain : As a resource/data owner they need to be able to control who can access the information while following specific policy for access.
The availability of the identity, access and resource management as a service which can be tapped into by the business groups may be a way to solve everybody pain"
Before we continue on this topic I would like to bring out the basic idea of a security / Identity Domain. Basically, it extends from the very common idea of defining scope of the system. This domain can be a single department, multiple departments, a single enterprise or multi-enterprise. It is very important to define the domain and keep that in mind while understanding the requirements. So basically this needs to be achieved taking in to consideration that there are three aspect of the R.A.ID Management( ;-) ).
  1. Resource: this, at the moment, needs to evolve as a concept. The products have concentrated on the I.T. Resources(provisioning for server, database, ERP or other third party product) and, in some cases, User Data (privacy manager), but at the same time resources can be any asset like IP address, Multicast address, in-house application(and associated data), web services, etc.
  2. IDentity: This is the something that seem to be the center of attraction at the moment. The basic concept being that every physical / logical entity that needs to be identified has to have a unique identifier in the domain. This identifier must then be mapped to all the digital representations in various applications / resources / Tiers / roles in the domain. Typically these identities have associated information which is referred to as user information / attributes, password, users' application data, etc. People have tried to define the concept of identity as three tier models and you can check out the link for complete discussion on the subject. I do not "get it" completely but I will re-visit this topic.
  3. Access Control: This bring together the identity and resource. The most popular model of access control is based on the two component system - Access Enforcement Point and Access Decision Point When ever the user tries to access a resource, the resource manager(entity that interacts with client and serves the resource) or a associated component acts as an "Access Enforcement Point". It needs to know
    "Is User X Granted Permission Y On Resource Z?"
    The "Access Enforce Point" typically defers the question evaluation to an "Access Decision Point" which has the access policies that enable it to make the decision and return back result to caller. A typical policy may be of the following form
    "GRANT|DENY User|{Static or Dynamic Group} X Permission Y on Resource Z if constraint is true"
    I will expand on this concept later(TODO - Add URL). These policies and additional information should be available at the Access Decision Point so that it can evaluate the query and return information.
In the next sections I will take each of the component separately and discuss the concepts around each of them. There would be 3 sections about each component.
  • Concepts This will discuss the basic concepts associated with each of the component and important ideas that should be kept in mind.
  • Runtime This section will discuss the typical components that are come into the play at runtime.
  • Management This section will discuss the typical concepts associated with managing the component