Tuesday, December 12, 2006

Federated Authorization and Relationship

The post from James McGovern[duckdown.blogspot.com] on federated authorization resulted in response from Pat Patterson[blogs.sun.com] and Paul Madsen[connectid.blogspot.com]. First of all I would like to really thank Paul for providing the link to one of the best docs on entitlements that is out there i.e. Conceptual Grid Authorization Framework and Classification[gridforum.org]. It should be a required reading for all the people who enter in to this domain.

But at the same time, I am disappointed that Paul missed another approach mentioned in the document ( or may be I am missing something). Pat rightly identified the 2 typical models that can be implemented and Paul extended it by coming up with all the permutation and combinations using various components. But all the model discussed look to be various permutation of just one model i.e. Authorization Pull Model where the resource is resposible to connect to the Decision Point to get the result. I think a hybrid of the "Authorization Push Model" and Local policy evaluation is more appropriate for the federation model where along with the identity the authorization of subject itself will flow to the other domain. This is approach is defined by SecPAL[research.microsoft.com] (I hope this will become more mainstream and discussed in near future). In addition to that I would like to see more discussion on other policy languages beside XACML including Cassandra and SecPAL.

Another good point raised by James is the concept of relationship and how that should be part of the identity domain. With the rise of social networking this is a good usecase for the internet identity solutions like openID to solve. I do not think that this is a tough problem and I think that it can be solved by mapping it to an attribute or contextual role problem (similar to who has approver role in the context of given user which everybody is trying to solve in provisioning). But it is important to bring in a standard process for trust establishment and standardize the way in which the relationship are shared between various platforms.

My thoughts on the integration scenarios in next few days.

Thursday, November 23, 2006

Entitlement Management - What are we trying to solve?

It has been 3 months since my last posting and this post has been triggered by a few events. First of all there was a great gathering of Financial Services on various topics including entitlements [senasystems.com] (sorry could not find any other reference to the meeting without the marketing fluff). In addition to that securent (a vendor in entitlement space along with CA, BEA and few others) was out of stealth[internetnews.com] mode which triggered some[zdnet digital id blog] discussion[Connexitor] in the blogosphere but nothing close to what I was have been expecting (most of the people seems to be discussing the "internet identity" way too much[James McGovern] and I guess that is because it is for the people, by the people and hence discussed a lot between the people) to happen in this space. I am guessing that most of the people who are trying to solve the entitlement problem are actually trying to solve it instead of discussing about it in public or discussing with other people who are working in this space without sharing with others. Please note that this does not include James McGovern and few other evangelists that I know of in financial services.

Anyway getting back to the panel discussion, after a good discussion on the topic one of the very good question was what are trying to solve within the entitlement management space. Most of the panelist agreed that taking up centralized and standardized entitlement Administration with centralized and distributed Policy Decision Point was a good start but that it is not an end in itself. There are still use-cases that can break that model (for example applications with very large number of resources that are individually protected or complex User based ACL for users in millions) and would probably be out of scope from such systems. So, what is the solution?

The way I see it, the solution or solutions will depend upon what are the drivers for an enterprise.

For most of the financial services firms, due to the compliance being a very important, visibility is most important driver and then the next in line is control. The visibility means that there should be a way to make the entitlements within a particular system made visible to the auditors, et al. Now this can be achieved by either using the batch mode using standardized policy model (XACML is good start but does not cover everything that is needed) that I described earlier or by making the application provide a standard interface to answer the queries the auditors may have in realtime(each approach has it's own pros and cons and I need to think more about them).

On the other hand if it is the control of the entitlement model which is more important then a centralized and standardized entitlement Administration would be a good way to proceed. Now that in itself means that for each new system, you will have to translate the Admin policy model to application policy model. This policy translation can vary from being very easy for policy model which are very simplistic (for example in case of User ACL  you can just evaluate the policy model for each user and push the result to application entitlement repository) or models that are very close to standardized administration model(which hopefully is a broad model). In case of rest of the applications, the model translation may not be possible since some of the components used for modeling the policy in the administration system may be missing and there may not be any way to translate them to something that the application may understand (this can be mitigated by ensuring that the administration system model does not contain policy constructs which can not be consumed by the application).

In case the driver is getting the security model implementation out of developers hand, then the centralized/distributed Standard Decision Point (and associated policy model administration) may be the way to go or incase of standard container managed systems a Standard Enforcement Point can do the trick.

At the same time in most of the cases there are multiple drivers and so people may have multiple solutions in place to solve the problem.

Anyway what ever are the drivers and corresponding solution set that an enterprise needs or implements, the next step is to integrate with existing Identity Management infrastructure(that's for the next blog entry).

Another good obvious question was how to choose the applications for the new entitlement management platform/solution that people are building and there were some good answers esp. with regards to using the following criteria

  1. New Applications are good candidate for the new platform (SOA anyone?)
  2. Application that have hit wall w.r.t. entitlements and are themselves looking out at vendors to solve their problems
  3. Applications with new audit requirements may be another good candidate for the platform.
  4. Evolution vs. Revolution - May be I did not choose the right words but guess the discussion was around the idea of whether you should choose the most difficult/visible application (revolution) and prove the platform or make small gains with well selected non-critical applications. In addition to that most panelist agreed that a good choice could be an apps of low criticality but highly complex policy model which validates the platform and at the same time the setbacks due to initial platform gliches will not become a big mess). One of the participant suggested the idea of using usage footprint with frequency of use to identify the new application.

After you have a platform in place the next step is to evangalize the platform within the enterprise (and even outside). There was a good  discussion on how to go about doing that

  • Internal Developers - Even though there was a skeptism about whether Application Developers would accept the new platform as an integral part of application development without "shoving it down their throat", it seems that many enterprise have had a good experience on that side in terms of letting the word about the platform spread through "word of mouth" based on initial success of a few applications.
  • Outsourced Development - This is something that can be tackled through standard development process or letting the application architects buy into this platform. But at the same time I think some standardized APIs for Java (no JAAS is not the answer) and .NET may be a good starting point.
  • Product Vendors - This is a very important field of people with whom this process needs to be repeated right now so that just like the Web SSO support has become an integral part of the development process, the vendors should have a good understanding of this domain and a well formulated strategy on externalization of policy enforcement/evaluation/administration. 
  • Service Providers - This new breed of SAS is something that most people are not thinking about at the moment but may be something that becomes important (may be pushed by federation) going forward.

The session overall provided a good insight into the lack of good understanding of this space not interms of what needs to be done but what is the best way of doing things.

Please note that this post is not a news piece and contains the various concepts from different people as I understood and have been tarnished by my thoughts on the subject (which may be totally wrong).

Hope this helped.

Saturday, August 26, 2006

Representing Authorization Model

I read xacml [James McGovern] entry around representing the authorization model. He has raised a great point on how to translate the authorization use-case narratives in to a simple representations. So far based on the various conversations around the authorization models, I have not been able to find a way to represent the complete authorization model as a diagram. The simple reason being that at the core of the authorization model are business rule and it is tough to represent them as diagram. Let me elaborate on that.

Basically, when you start looking at the authorization use-cases, at a very high level the following components typically form the part of the authorization data model

  1. Users and their organization into groups, roles, client organization, etc
  2. Resources and their organization into hierarchy, groups, etc
  3. Actions and probably some form of their organization
  4. Attributes of the user, resources (and may be actions), environment that help perform fine grained evaluation
  5. Policies which are the business rules (i.e. a combination of corporate, LOB, application security rules) that bring together the user, resource, actions, their organizations and attributes.

The items 1-4 can probably be represented as diagram (but I still have reservations about representing the business logic for complex organization memberships). Incase of 5, some of the simple like ACLs may be represented using the diagrams. But when it comes to complex rule-based access control, the basic question is how do you represent business rules in diagram? Most of the places that I have seen, the business rules are represented using language and not as diagram (but I am not an expert in business rule representation and would love some pointers in this direction).

Can we use XACML for this purpose? The way I see it, XACML as it stands right now is way too simplistic. It is not appropriate to represent complex authorization patterns satisfactorily. I may get beaten up on this, but I think XACML at this time is more like SOAP of old days without any of the WS-* specifications to standardize the basic cross-cutting requirements. I think over time, through the various profiles (hopefully which are pretty intuitive), we would be able to standardize on more complex patterns which will help us represent the complex authorization models as diagram.

Besides that a very good point raised is around the requirement of mapping the existing authorization model to vendor data model (referred to as reverse engineering if I understood correctly). Now this is a very tricky subject since there is no right way to perform the mapping. Most of the time the application authorization data model  is not built around the simple user, role, resource, action system (unless the architects were really building under the constraints of following that model and the business requirements were simple enough) that automatically translates to the model provided by most of the vendors. The actual translation of the application model to vendor specific model (which vary in their richness and complexity a lot) is dependent on various constraints like

  1. Manageability requirements
  2. Data location and synchronization
  3. Authorization Queries that need to be fulfilled now and in future
  4. flexibility required in the future
  5. performance of vendor functionality being used
  6. and so on....

So, to reiterate there is no single way to transform Application authorization model to a Vendor specific data model and so coming up with a methodology which takes into consideration the various possible issues (like some specified above) is the best way to do it. 

My thought process at this point may look very pessimistic but would love to hear thoughts on this and would like to be part of any initiative that tries to solve this issue.

Thoughts and Next Steps?  

Saturday, August 19, 2006

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

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
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 management. In the field of Identity and Access Management, the evolution of the attempt to address the IAM problems can be described so far as
  • Consolidating Identity Data through Enterprise Directories which reduces number of copy or digital representation of User Identity that exist within an enterprise.
  • Consolidating Authentication/Authorization End-points Through Web Single Sign On solutions and Reduced Sign On solutions which reduce the number of authentication and access enforcement points.
  • Consolidating Identity and Access control Administration Through Provisioning products along with Meta-directory, password synchronization and self-service tools which reduce the number of administration tasks that need to be done with regards to managing identity and access control information.
In order to understand these various technologies, I will try to cover the following topics for each of the them
  • Driver for the technology
  • Hinderance or shortcomings of the technology
  • Glossary
  • Use case that the technology addresses
  • Data Model
  • Architecture
  • Some examples from opensource world
This edition, covers the Web single sign on (Web SSO) technology. Please check out this introductory article to get some idea about the identity management.

Driver

The basic set of drivers for the web single sign on technology has been
  • User Experience fewer logins means less time spent remembering password, resetting password and typing passwords i.e. higher productivity.
  • Extract Security from Application Most of us would agree that it is tough to get security right esp. for the people whose strength is the business side of the application. Technologies like Web SSO ease the burden of security from the shoulder of business developer and allows them to concentrate on developing business solutions and add security later. Even though this approach takes care of only one aspect of the security, it is a one less thing to bother about.
  • Compliance and Audit A lot of laws around audit and compliance have made it important for enterprise to answer the question "who accessed what when?" and these audit facilities have not been built in to a lot of legacy applications. Besides that it is costly to replicate them across all the new applications. The Single Sign On solutions allow you to centralize audit and hence monitor compliance. In addition to that single sign on systems come centralized management system which allow a better management of the policies that are enforced at point of entry.
  • It's the economy, Stupid!! - fewer passwords means fewer calls to helpdesk to reset password.

Hindrance

There are a few issues that should be considered
  • One key to Kingdom With simplification comes the risk accumulation in terms of the basic issue that there is only one authentication between a rogue user and all the services available. This can be mitigated by using strong authentication and repeat/stepup authentication(repeat authentication is a requirement to the user to re-login prior to high value transaction or access to sensitive information, while, stepup authentication refers to the idea of using different authentication factor like token compare to password used for initial login prior to high value transaction or access to sensitive information).
  • Application Integration With single login comes the nightmare of onboarding existing and new applications. This can vary from being very simple like installing available single sign on adapters to very complicated third-party product changes not supported by third party. This is one of the most expensive part of single sign on implementation and sometimes dwarfs the cost of single sign on product itself. Besides that not all legacy applications can not be integrated with the Web Single Sign On technologies.
  • ...

Glossary

Most of the products have developed their own glossary of terms but most of the them share common terms which have pretty close definitions. But in order to develop a discussion which is more meaningful, we may need to standardize on the definitions. There are a a lot of definitions that  have been developed and I will try to use them as much as possible.
  • Audit - The process by which selected events are stored in persistent and resilent repository for monitoring and future review.
  • Authentication - The process by which the User identifies itself to the Web Single Sign On System
  • Authentication Channel - The process of authentication involves exchange of data between user and Web SSO System. The medium over which the exchange of data happens is called Authentication Channel. In most of the Web SSO systems this typically happens through browser over the network. But incase of two channel authentication method additional channel like email, mail, cellphones may be involved.
  • Authentication Factor - Typically an authentication method can be classified into one of three types i.e. what user knows, what user has or what user is. Each of these types are referred to as an Authentication Factor.
  • Authentication Method - The authentication can be performed using a wide variety of methods (based on something that user knows, has or/and is) like passwords, certificates, tokens, biometrics. These are refered to as Authentication Method.
  • Authorization - The process by which Resource Manager or Web SSO system, identifies whether the user can access the requested resource. Please check this location for more information about this topic.
  • Browser is the application used by users to access the web application. This includes, but is not limited to, PC browser like Internet Explorer, Mozilla Firefox.
  • Cookie is a mechanism used by Resource Managers and Web SSO systems to store some data on browser used to access them.
  • Identity Aware Application is an application that performs additional processing like personalization, data  control and transaction management based on identity of the user performing the transaction.
  • Resource Manager is the a device that has the capability to accept the request for resource from browser, map it to appropriate entity (data, file, business function), retrieve the entity (if user is authorized) and return it to the browser to be presented to the user. This is typically represented by Web Servers and Application Servers.
  • Session timeout - The preset time interval after which the user session is  invalidated. Typically two types of session timeouts are used i.e. hard-timeout and idle timeout. Hard timeout is the duration after which user session is invalidated irrespective of the state of the user interaction with Web Applications. Idle time is defined as the duration during which there is no browser Web Application interaction. Idle timeout is defined as the idle time after which a user session is invalidated.
  • User is an entity that needs to access multiple web applications to retrieve data, perform transaction or manage system itself. User may represent an actual person, a group of persons that share common identity, another application that needs to access data or perform transaction on behalf of one or more users. Typically a user that has the capability to manage the Web SSO system itself is referred to as an "Administrator".
  • User Session is the continuous time interval during which the Resource Manager provides access to its service to the user. The session starts with user accessing the Web Resource through the Resource Manager and  typically starts with successful authentication and ends with a direct action from the user (closing the browser, performing logout) or indirect action by Session Manager (session timeout, Administrator logout).
  • Web Application Any identity aware application that can be accessed over the network (either intranet or internet) using browser.
  • Web Resource/Resource is the information, transaction that user needs access to and which is part of a Web Application. This is typically represented by URL.
  • Web Single sign on (Web SSO) The facility which allows a user to access (if authorized), for a limited time (user session), multiple web applications, which exist in same security domain, after  authenticating once.

Use Case

There are multiple use-cases associated with Web Single sign on systems. These use-cases can be divided in to two category i.e. Runtime and Administration Use-case (the format has been borrowed from the OpenSSO use-case document).
  1. Installation (Administration)
    1. Summary - An administrator would setup and configure the Web Single Sign On environment 
    2. Prerequisite - None
    3. Actors - Administrator
    4. Main Success Scenario - A scalable, failure-resilient, architecture must be developed. All the components get installed properly and installation checklist is passed.
    5. Alternative - There are a lot of product specific dependencies that may lead to failure of the installation. Please consult the product specific installation guide.
  2. Application Onboard (Administration)
    1. Summary - An administrator and Application developer would setup the Web SSO and change application to provide a Single Sign On experience to user.
    2. Prerequisite - Web SSO and Application have been installed.
    3. Actors - Administrator and Web Application Developer
    4. Main Success Scenario - Administrator is able to setup the various Authentication and authorization requirements for the Application like
      1. What are the various authentication methods that application needs and what is their hierarchy?
      2. What are the authentication factors and channels, if any, dictated by the application's authentication and authorization model?
      3. How does the application want to control access to the URLs, Web Components? For example which URLs may be accessible to everybody, which URL require authentication, specific URLs that need 2 factor authentication and so on.
      4. What additional user specific information (like user's roles, attributes) need to be made available to application (since the application is not managing the identity but trusting and reling on Web SSO for the identity information)
      Besides that the application developer needs to change application so that
      1. Application is no longer performing authentication or URL level authorization which can be performed by Web SSO system
      2. Application does not store and retrieve the identity information which can be provided by Web SSO system through its interface (e.g. HTTP Header, API, Cookies, etc.)
      3. Application session management is synchronized with Web SSO in terms of session establishment, timeouts, logout. 
      4. All the functionality of the application work after Web SSO sytem has been added to infrastructure. Eventhough in most of the product scenarios this is not an issue, due to the architecture of some of the other products this used to be a big issue. 
    5. Alternative - Due to non-availibity of web application source code or non-availability of the configuration parameter, the application onboarding could be a very tough or unsuccessful exercise.
  3. User Login (Runtime)
    1. Summary - A user accesses the Web Application protected by Web SSO
    2. Prerequisite - Web Application has been onboarded
    3. Actor - User
    4. Main Success Scenario - Please see below for the detailed description
    5. Alternative - Please see below. Password Reset, Self-service, Self-registeration. 
    The steps that typically occur during the sign on are as follows
    1. User uses browser to request access to resource(URL) to resource manager (Web/App Server + Web SSO product).
    2. Depending on Web SSO architecture, Resource Manager may receive the request and passes it to Web SSO for authentication and/or authorization or Web SSO may intercept the incoming request to authorize it.
    3. The authorization process would involve the one or more of the following steps in the given order
      1. Session Identification - The Web SSO system checks for the presence of a session identifier (typically a cookie) in the request. This session identifier is used to identify the session data by Web SSO on its side. In case it is not available a new identifier is created and a corresponding session object is added to Web SSO's session "table". In order to provide automatic session failover, some products may package the complete session data into a cookie (encrypted ofcourse). This can then be used by Web SSO or Resource Manager to establish a new session without requesting user to login again.
      2. Anonymous Access - If there is no user identity associated with the session, the Web SSO or Resource Manager will check whether the resource can be accessed anonymously. If successful, it will provide access to the request resource otherwise it forces user to authenticate.
      3. Authentication - If no user is associated with the session, based on the configured authentication method and channel, the user would be asked to authenticate by the system. If Web SSO determines that authentication was successful, user data (like user attributes, roles) is collected, processed (for example user mapping), stored in the session securely. After the authentication is complete, a pre-configured step like requesting user to approve an access policy or user-profile update may be performed. After this has been completed successfully, either Web SSO or Resource Manager would perform authorization. If authentication is not successful one or more of the following steps may happen
        1. If there is pre-configured maximum consecutive invalid login attempt (for example 3) trigger set, that may be activated after user fails to login and result in
          1. The account being locked out for a pre-defined time interval (referred to as account lockout interval) after which that particular user id can be used to login.
          2. The account being locked out permanently and may require user to contact administrator (or help desk that provides the administrative service) to "unlock" the account
          3. The password reset page may be displayed to allow user to reset the password and unlock the account.
          4. The system may switch to a different login process. (for example if SPNEGO authentication is being performed and that fails, the user may be presented a form based login to authenticate)
        2. Otherwise the user may be provided another chance to perform the login.
      4. Authorization - If a user is associated with the session, the Web SSO or Resource Manager checks whether the user id is authorized to access the resource. If authorized then the Resource Manager provides access to the resource otherwise it may return an access denied error or, if possible, it may force user to perform setup authentication.
      5. Audit - The status of all the successful and failed events, along with information like user identity, IP address, URL, date and time  associated with the event, is stored  in a resilient repository for monitoring and future review purpose.
      6. Stepup Authentication - Some times due to authorization requirement, it is required that the resource may accessed by using more secure authentication method (for example two factor or two channel authentication or same authentication). In such scenario, Web SSO system forces the authenticated user to perform authentication. This is referred to as Step-up Authentication.
    4. After the Web SSO has sucessfully validated the authentication and authorization,  it may provide additional information to the resource manager by adding identity data, like identity roles, groups, attributes, to the request. The resource manager may authorize the request and then send the application home page (resource) after performing personalization, if required, based on user information received from the request or Web SSO. Please note that the resource manager accepts and trusts the user data provided by Web SSO.
    5. The response generated may be authorized by Web SSO and may undergo transformation for various purposes.
    6. The browser will receive the response and which it provides to the user.
  4. User Global Logout (Runtime)
    1. Summary - An authenticated user performs logout from the Web SSO system
    2. Prerequisite - User has an active session with Web SSO. 
    3. Actor - User
    4. Main Success Scenario - After the user has performed authentication, they would be able to access the web application directly. In that case the global logout functionality can be provided in following ways
      1. Application Link - The Application would provide the link to the special URL which will be captured by Web SSO or forwarded to Web SSO by Resource Manager to trigger a session termination
      2. Web SSO Addon - In case the Web SSO or the application provides the capabilities (for example portlets in Application Portal), the Web SSO can be exposed as an integrated component within the application through portlets, IFRAME, etc which will allow user to perform a logout.
      3. Browser close - Incase the user decides to close the browser, there might be a javascript that gets triggered by the close event and invokes the global logout link from the browser.
      On activating the global logout, the Web SSO terminates the user session, may inform the applications to terminate their sessions, and may redirect user to a pre-configured application/user/web sso specific page if browser is available.  The Web SSO must audit the event for monitoring and future review.
    5. Alternative - None.
  5. Bookmark/Timeout (Runtime) 
    1. Summary - A user uses a bookmarked URL to access the web application or access a functionality of web application after either hard timeout or idle timeout.
    2. Pre-requisite - User does not have an active session with Web SSO.
    3. Actor - User
    4. Main Success Scenario -
      1. The user uses either a bookmarked URL or an invalid session (not known to him) to connect to the Resource Manager.
      2. The Resource Manager or Web SSO intercercepts the request and determines that user has not authenticated or is using an expired session and redirects user to Web SSO for authentication.
      3. The Web SSO must audit the event for monitoring and future review.
      4. If the authentication is successful, user is redirected to resource manager with the URL that was being used earlier to access the request.
      5. The resource manager may choose to either display the requested URL or redirect user to the application home page
    5. Alternative - Incase authentication is not successful, authentication error is displayed and user may use password reset, self-registeration use-case.
  6. Self-service Password Reset (Runtime)
    1. Summary - A user has forgotten the password/shared secret and wants to reset the password/shared secret.
    2. Pre-requisite - User already has an account with Web SSO.
    3. Actor - User
    4. Main Success Scenario -
      1. User would go to password reset screen by either clicking on a link or may be redirected to it by the web sso system after login failure.
      2. The password reset system may provide one of the many available process to validate the user
        1. Question/Answer - This is one of the most popular password reset system where the user provides answer to pre-defined/selectable/user-defined questions at the time of registeration (or when they may authenticate for the first time). During the password reset process one or more of these configured questions are presented to user for answer and depending on the setup, the number of correct answers to question would determine that the user is a valid user
        2. Multi-channel - Incase the Web SSO has information about another channel to the user (for example a pre-registered cellphone, phone, email address), the possesion of that may be used to validate the user. This can be done by sending a token, special URL to the second channel and the user may be required to use the primary channel (i.e. browser) to provide that token to Web SSO to validate himself.
      3. After the validation has been performed, the new password needs to be set. A variety of processes are used to fulfill this step
        1. One-time or permanent Password via Other channel - The new password is provided to the user through another verified channel like email address, cell phone, etc which can be used by user to login once and then change the password.
        2. Direct password reset - The user would be allowed to set the new password directly after the validation has been performed.
      4. The Web SSO must audit the event for monitoring and future review.
    5. Alternative - If the password reset is not successful or the requisite information about the user is not available for password reset, the user may have to contact Web SSO Administrator or helpdesk to reset the password.
  7. Self-registeration (Runtime)
    1. Summary - Users needs to register themselves with Web SSO system before accessing the application
    2. Pre-requisite - Web SSO system is installed and configured. Application is configured.
    3. Actor - User
    4. Main Success Scenario -
      1. User tries to access the Application and is redirected to Web SSO authentication page where they are provided link to register or User clicks on a self-registeration URL made available to him by email, application home page, etc.
      2. User is presented with form to provide all the relevant information that is required by Web SSO and the application including authentication method related information like user identity, password, question/answers, as required. Please note that due to the growing privacy concerns and potential issues w.r.t. personal identifiable information, it is recommended that only minimal information needed for personalization and validation must be requested from the user.
      3. The information provided by the user is verified against data validation policy (for example password policy may state that password must be more than 8 character with numericals and symbols, SSN must be specified format, email address must be owned by the user). Some information needed to complete the self-registeration may be generated based on user data (for example in some case user id may be system generated).
      4. The required information is stored in the Web SSO's Identity Repository for future access.
      5. The Web SSO must audit the event for monitoring and future review.
      6. User is informed that registeration has been completed and he may be requested to login and then redirected or automatically redirected to the requested URL.
    5. Alternative - Incase the user is unable to complete the registeration, he may try at a later time or call the Web SSO Administrator (or helpdesk). If user data validation can not be completed, user may have to contact Web SSO Administrator (or help desk ) to complete the process.
  8. User Provisioning (Administration)
    1. Summary - User that needs access to Web SSO system is provisioned by external system or application
    2. Pre-requisite - Web SSO system is installed and configured. Third party provisioning system is setup to provision the user to Web SSO based on an event.
    3. Actor - Provisioning System
    4. Main Success Scenario -
      1. Due to an event in the Provisioning System (like new employee, customer, assignment of a role), the system may decide (based on the setup) that user needs permission to access a specific application protected by the Web SSO system
      2. Provisioning system may have direct access to the identity repository used by web sso system or it may have access to web sso system through the Web SSO Administration/Provisioning API.
      3. Provisioning system would check whether the user is already present in the Web SSO system (or its repository). Incase it is not present, the user information will be added to the Web SSO system using API or direct calls to the repository. Incase the user is present only the necessary changes needed to enable the new application is performed.
      4. Both Provisioning System and Web SSO must audit the event for monitoring and future review.
    5. Alternative - Incase the provisioning fails, the provisioning system may need to fallback to a failure workflow which may require notification to Web SSO Administrator (or help desk) to manually add the user to Web SSO system. 
  9. Self-service for identity (Runtime) 
    1. Summary - User that needs update his information into or un-register themselves from the Web SSO system
    2. Pre-requisite - User has an active session with Web SSO system and the system provides the capability of self-service
    3. Actor - User
    4. Main Success Scenario -
      1. Dependening on the way in which the Web SSO exposes its services (as described in the global logout usecase), user would click appropriate Web SSO specific link to access the self-service interface.
      2. User can choose to update its information in Web SSO or provide his preference to unregister from the Web SSO service.
      3. Incase user chooses to update his information, Web SSO would store the updated information in its repository and then redirect user to the homepage or the application being used prior to the self-service.
      4. Incase user chooses to "unregister" them selves, the Web SSO should tag the identity for future deletion or delete the information immediately. In addition to that Web SSO may indicate to the Web Application it protects that user has "un-registered" himself and all his information must be removed (or tagged for removal) from their repository. The event must be audited and no audit information about user is removed.
    5. Alternative - Incase the update or un-registeration fails, the Web SSO Administrator (or help desk) may be contacted to update or un-register the user as needed. 
  10. Identity Synchronization (Administration)
    1. Summary - In the event of user data being updated or user being de-provisioned in the provisioning system, Web SSO system needs to be updated
    2. Pre-requisite - Web SSO already has the user account for the corresponding user.
    3. Actor - Provisioning System
    4. Main Success Scenario -
      1. Due to an event in Provisioning system, the user data needs to be updated in the Web SSO system or user needs to be de-provisioned from the system
      2. The provisioning system would use the Web SSO API or the Repository specific interface to update or delete, as needed, the user from the system.
      3. The information may be removed or tagged to be removed from the system.
    5. Alternative - Incase the provisioning fails, the provisioning system may fall back to failure workflow which may require notification to Web SSO Administrator (or helpdesk) for manual provisioning.
These are the use-cases that could think off. I would really appreciate input on these usecases or any additional use-cases that you guys can think of. I will write about the data model and architecture of the Web SSO system.

Friday, June 30, 2006

User Centric Identity: MY Take

I stumbled upon the User-centric Identity Discussion today and thought I would provide my thought on the same. As part of that article/post I ran in to the comment
"It's my identity. It is not one conferred upon me by an organization outside myself. It is not a representation of me in a context other than my autonomous and independent self, operating in the larger world we call the marketplace. This is the identity we hope to more fully empower by our various projects."
I am a bit confused about this one. I have never understood the concept of MY Identity. I understand what this is proposing but the way I see the identity, it is something beyond I, Me, Myself. As I have said earlier, that the identity can not exist in absence of relationship and so far I have not seen anything in these discussion that would change it. So, the idea of My identity, the way I see it, is just the way I have built an identity about myself based on the relationship I have with me. So, if I think I am the king of the world who is the most confident, blah, blah guy in the room, that is my identity about myself.
This does not mean that others have to accept my version of myself as the way they identify me. This mismatch in the external perceptions (i.e. external identity) and internal perceptions (i.e. My Identity) creates a lot of problems in the world but that is something I guess most of us know about.
Let's look at the second phrase of "not one conferred upon me by an organization" kind of surprised me. I am not sure I understand but which part of the identity of a person (besides the personal identity) is not conferred by external entity. Even our names and aliases are conferred by external entity (if "me" does not include parents, friends, siblings or even enemies in some cases). For that matter, if we want others to accept our new identity (as new names), we are dependent on "those organization" (which most probably will be courts, friends and family) to accept our new identity. This reminds me of a story titled "A table is a table" (Sorry could not find a link) which takes a look at a person who starts calling everyday objects by different name just for fun and over time forgets what rest of the world actually calls it and I am sure most of the people can come up with endings of what happens to him in the end.
I think the idea of "No body knows that you are a dog on internet" and escape that virtual identity provides from the real world identity has gotten people too much excited about the idea of them being able to control their identity. This may make be sound like a downer, a conformer, but it seems the complete control is not possible if you see the identity as the perception others have of you in their relationship with you.. I am as happy as the next person when it comes to the idea that every body should see me the way I see myself. But that does not work in real world. In real world the identity is governed by various thoughts, notions, interaction that other's have with me or about myself.
I am not sure whether I actually explained it well but the way I see it
user-centric identity is about an attempt to bring our internal identity closer to external identities. By collorary, there should be only one identity about myself in the world which should be same as MY Identity.

Sunday, June 18, 2006

User Centricity of a relationship and protocol

This entry was written based on my existing unhappiness with user-centric identity definitions and some thoughts on the "user-centric identity" discussion that I read at [Eve Maler - Sun: R-E-S-P-E-C-T], Paul Madsen: A protocol for the people and Pete Rowley - People in the protocol
As I have said earlier , the user centric identity infrastructure must have three components i.e.
  1. User having some level of control what they need to disclose to existing or new acknowledging entity [User-Ack]
  2. User have some level of control on what information acknowledging entity can receive about them from 3rd entities. [3rd-Ack]
  3. User have some level of control on what information acknowledging entity can give to 3rd entities [Ack-3rd]
  4. User have some level of control on what 3rd entities do with the information that they recieve from acknowledging entities and other 3rd entities.[3rd-3rd]

Intent and Share Event
Now the control of the identity data can be done at intent or share event level. For example, any protocol or relationship before accepting the identity data would tell user it has intention to provide the information about the user at a later stage with other entities. Or the protocol or relationship could be designed so that it allows user to control the identity data transfer only at the point where it is needed by a identity data enabled protocol.
Control Level
The level of control itself can be classified as follows
  • none - user is not in the loop when it comes to any of the attributes being shared in any relationships
  • inform - user is just informed about the intent and/or event of data transfer between any two entities. Most of the websites privacy policies would probably fall into this category.
  • monitor - user is able to monitor the intent and event of identity data sharing as it happens. This level is slightly different from the "inform" level. The "inform" happens only after the intent or event has occured. While monitor requires the acknowlegement of intent or share event by the user before it completes. Please note that in this case the protocol or relationship does not provide any recourse to identity entity/user to stop the event or intent. But at the same time the user may be able to stop the same by involving external agencies.
  • Concent - user would be able to control whether the particular intent or event ever happens. This is where most of the brick and mortar companies would probably place their privacy policies.
Control Granularity
Now it is pretty clear that this is just one aspect of the user centric control system. Other aspect is the granularity of the control with regards to with whom data is being shared. For example, there has to be a way to differentiate two entity who may allow capability to control shared at everybody or nobody level vs per-entity level(like identity providers of future in the "identity 2.0" world).
The granularity can be classified as
  • All - This is the most coarse grained control level where user can only tell whether all or nothing can be shared with other entities.
  • Class - The sharing entity itself may classify its relationship with other entities in to various classes (like legal vehical, legal entities, affiliates, partners, marketing agencies) and would allow user to control the information at that level. Most of the brick and mortar companies (atleast my bank) privacy policy would probably fall into this category with regards to granularity.
  • Entity - This would allow user to control the data share at legal entity level.
Data Granularity
Besides the granularity of the involved entity, there also need to be granularity with regards to data being shared such that,
  • Identity - This would allow user to control whether all or none of the identity information available can be shared.
  • Attribute - This would allow user to control the data share at the attribute level itself.

User Centricity
Now bringing these four things together i.e. intent/event, control level and control, data granularity allows us to classify a protocol's "user centric" level or user centricity (Sorry could not stop myself from inventing yet another term).

A user centricity would be defined as a combination of the control level and granularity with data granularity for the intent AND share event of a given protocol or relationship (may need to work on the sentence. Thoughts??)

This term is applicable to any identity data enabled protocol (i.e. a protocol that requires identity data to function). We should be able to define the user centricity of any identity data enabled protocol by the combination of control and granularity level for the intent and share event.
So for example the credit card application that I received today in my mail, did not have any information about intent of sharing (intent-none) but hopefully incase I form the relationship I would be allow be control share event by concenting for all my identity data with various classes of entity (share event-concent-class-identity). This would define the user centricity of the protocol between myself (identity entity) with my credit card company (acknowledging entity) i.e. [User-Ack] and the creditcard company with 3rd entity (i.e. [Ack-3rd]) as [intent-none,share event-concent-class-identity]. With regards to other protocols i.e. [3rd-Ack], if undefined then the user centricity of that protocol is [intent-none, share event-none].

I think that even though we have defined the user-centricity of the various identity data enabled protocols, there has to be an overall measurement of user-centricity of the relationship between myself and the creditcard company. I think just like with any other data security system, the user-centricity is as good as the weakest link. So this would probably put my relationship with credit card company as [intent-none, share event-none].

Thoughts?

Thursday, June 15, 2006

User Identity: Relationships and Trust

I ran into this entry on Identity - Management and trust[Discovering Identity - Mark Dixon] which took me on the following thought sequence. Please note this rambling is more of a tomato/TomATo discussion so if you have some thing better to do skip this one.
Identity and Relationship
Identity, the way I see it, is about perceptions that a acknowledging entity has of the identity entity. First of all, an identity can not exist without a relationship. This relationship can be between you and any other entity (which can be person, group, corporation, etc.) or even yourself. But this raises a question well did you not miss the entity itself. Shouldn't there be an identity of entity itself which exist all by itself? Yes, the existence of the entity itself is necessary either in past (a star that has turned in to a black hole), present or in future (various elements in periodic tables that were identified but not discovered until later) but it not sufficient for the identity. Unless there is no need to identify the entity, the identity can not come in to existence. And the requirement for identifying the entity itself would mean that then exists another entity which is interested in acknowledging the existence (and hence the identity) of the entity. (I know most of you are thinking "What was that!") Sorry could not find a better way to explain the idea. I was thinking of coming up with a few examples but most of them I thought were a rehash of the idea of "If a tree falls down in the woods and no one is around to hear it - does the sound have an identity?"
Another approach of looking at this idea of relationship dependent identity (this is where I would like to thank the "upnishad" to help me build an "identity philosophy" ;) ) is to assume that identity itself is an ever existing ethereal "thing" which manifest itself in different forms (which is what we actually refer to as an identity for practical purpose) specific to a given relationship. This would mean that a person can have an identity of John Doe in the context of his relationship with his friend and an identity of number 123-45-6789 in the context of his relationship with his government and so on.
Identity Attributes / Description
So after we have identified the entity in the context of a relationship, the next thing that is comes into play is attribute / description of the identity. Understanding of identity's tangible or intangible attributes is result of various interactions that acknowledging entity is having with various entities (besides the identity entity) and perceptions built as a result of those interactions. The tangible attributes are attributes that can be measured or quantified. Now the measurement or quantification can either be performed by acknowledging entity itself (for example height, finger prints, psychological profile test, etc.) [direct attributes], received from another "trusted" entity (like name from driver's license, credit score from credit agency) [indirect attributes] or computed based on values of one or more direct, indirect or computed attributes (risk level of a client for mortgage application) [computed attribute]. Please note that this is the first time we have talked about trust in this monologue. Also note that the trust we talked about is between acknowledging entity and 3rd entity and NOT between identity entity and 3rd party. Which brings us to another point that I wanted to bring out i.e. identity is not built on trust. Trust becomes important only when it is not possible for the acknowledging entity to measure or quantify the attributes that it needs for the identity entity. Let's apply it to a web based banking transaction. Since the bank does not have a mean to measure the attributes to correctly identify the person who wants to do the transaction, it has to trust a computer (3rd entity) to provide the measured attributes that it needs to identify the identity entity. Now based on this chain of thought (I am not sure where I went wrong with my logic), I inferred that the explicit trust relationship is between bank and computer and NOT between person (identity entity) and the computer (3rd entity) or between person (identity entity) and the bank (acknowledging entity) or viceversa. Identity and Trust
In the previous section we talked about the how the concept of indirect attribute brings in the concept of explicit trust i.e. the trust that two entities have between each other. Now trust is (like identity) needs a relationship to exist. In this cynical world most of the people will see trust always in the context of the identity and transaction (i.e. entity A trusts entity B because entity A can identify entity B and its risk level attribute in the given transaction context is low) rather than another attribute of relationship ( i.e. entity A has a relationship with entity B for no apparent reason). Still assuming that trust is based on relationship we can think about reflexively (entity trusts itself), binary (if entity A trusts entity B then viceversa is true) and transitivity (if identity entity trusts acknowledging entity and acknowledging entity trusts 3rd entity then identity entity trust third entity) of trust between entity. Well based on our experiences we can say that none of these property is exhibited automatically by trust (probably reflexively in case of most of people :) ). But still in this world we try to build these properties on the trust through laws, contracts and past experiences, etc.
Now if we start looking at how the 3rd entity actually get the attribute that was available to acknowledging entity, we see that as a part of another relationship, that the user had with an entity, the identity for the user was established. This identity then was shared by the acknowledging entity with the 3rd entity. This means that the 3rd entity starts to build a perception about the the identity entity even though there was no explicit relationship between identity entity and 3rd entity. Lets call this relationship an implicit relationship. Given how quickly number of these relationships can increase, it would be really important to think about how these implicit relationships can be controlled (well most of the business solve it by asking their customer explicitly about their preferences).
User-centric Identity Management
So, to summarize
  • Identity is the perception that an acknowledging entity about the identity entity
  • Identity attributes can be direct, indirect or computed.
  • Trust comes into play only when acknowledging entity can not measure the attributes of the identity entity.
  • Trust can have reflexively (by default for most people anyway), binary and transitivity property built into it based on laws, contracts and past experiences.
  • Relationship itself can be either explicit (as in case of identity entity and acknowledging entity) or implicit (as in case of identity entity and 3rd entity that receive identity attributes from acknowledging entity).
So, based on the discussion itself, I see that if the users need to get control over their identity across all of their relationships, the following needs to happen
  • Identity entity should know and be able to track all their explicit relationships and attributes (Guess that is something that users will have to do unless there is some automated process to do that)
  • Acknowledging entity needs to tell identity entity about all their trusted relationship with all 3rd entities (as discussed in context above) and the indirect attributes they accept from these 3rd entities.
  • Acknowleging entity need to tell identity entity about all their trusted relationship with 3rd entities (as discussed in context above) and the direct attributes they provide to these 3rd entites.
  • The 3rd entity need to ensure that all their relationships with regards to attribute that they distribute or accept from other entities must be available either on per identity entity basis or in general.
Now this is not happening any time sooner so the next best thing is to ensure that all the data is masked before they are shared with other 3rd party. This without a proper data masking standard would defeat the whole idea of sharing the data (unless it is for consolidated analysis) or would it?
Till we solve these issues, I do not see the User centric identity being a reality. I see some vendor initiated client side identity management products who are trying to solve these issues using technology. But without a support from all the stakeholders (like frameworks and standards to share identity data between business, business themselves and laws or guidelines around these) I do not see anything like this taking off. I remember having a conversation last year in May in context of one of the vendors around the drivers for user-centric identity software and only possible driver that we could see was either law makers passing laws around this or some decisions in court based on the lawsuits on behalf of people who lose their identity data.
If you have reached this line would love to hear your thoughts.

Thursday, April 13, 2006

Take control of your Authentication (and Authorization/Entitlements)

It feels good to hear that people are realizing the difference between authentication and authorization. Even though it is self evident from the basic definition of Identity, Authentication, Authorization (Wikipedia) that these are three different things, I have a feeling people do not completely realize whether the current products in market allow them to solve authentication and authorization problems at application level.

When I talk to most of the clients who are trying to get control over their authentication and authorization, it is pretty clear that User provisioning, User-centric IDs (well they need to start thinking about Infocard), EAM/Web SSO products and Enterprise Reduced SignOn are solving only the authentication part of equation. Even though most of these product claim to solve the authorization, I do not think they understand it or are just doing at very basic level.

For example, EAM/Web SSO products are built to extract the authentication out of application and they do it pretty well. Most of these product would claim that they provide Authorization solution also. But if you look deep into them, these products support very simple Authorization policies and can only protect resources that people access through standard containers (like Web Servers, Application servers). You still have to rely on the authorization model of the application for actually controlling who has access to what. Incase of user-centric ID systems and federated SSO, it seems the only problem they are trying to solve is access control over user's data (besides core issue of federated SSO) and this makes them completely unusable for enterprise entitlement systems. The last but not the least the Provisioning products are limited by their capability to just make the target systems (i.e. application's identity repository) aware of User's Identity (and to some extend control its capability by assigning groups, etc) and can not provide a deeper understanding about what a user can actually do within the application.

But I think most of the enterprises will agree that what they are looking for is the capability of being able to answer something similar to the following questions when the auditors visit them next time

"What are the various financial resources that a user can perform specific action on?" "What are actions can the user perform on given resources?" "Who are the various users that can perform the given actions on given resources?"

Now eventhough some of the auditors may get satisfied with the answers like "these people belong to this role in application x" or "these people have access to application y" but I have a feeling most probably that may not be good enough in near future.

Besides that all the other reasons like taking security out of developers hands, making life of developers easy by reducing coding they need to do for security features, allowing security people to have a better idea about state of software security esp in terms of access control models, and so on are not completely solved by authentication systems.

At this point I would like to make it clear that all the work that enterprises have done so far for getting access control in order using various products is not waste. I am not suggesting that all these the previous stuff need to be thrown out and a new product must bought. My suggestion is to take a look at the need to complete the last mile of the Authentication, Authorization roadmap by looking at the application authorization model.

The application authorization model is the fine grained access control model that most of Identity aware applications typically have implemented in their code. This implementation can be in form of an accounts table in database with user id and account mapping, or a simple isUserInRole call in application. Such implementations have the basic flaw that the security model is not completely clear to any body (including developer in case of very large applications) and thus reduces the ability of people responsible for the security to generate accurate and complete access control models for various purposes (including audit and compliance) based on design documentation, collation of various replies from developers and so on. So, the ultimate goal is to develop a single enterprise dashboard that can provide (and possibly manage) authorization (and/or authentication) information.

There are various reasons why people may see this as an issue that needs to be rectified. Most of the typical reasons would probably be same as that responsible for earlier wave of Identity Access Management products. I would like to discuss the various approaches that can be taken to solve this issue. Just like other similar problems there are atleast three ways to approach this problem -

  1. Centralized and Standardized Monitoring - In this approach, there is a central monitoring/reporting system that receives the various application policy and associated events (that may affect the evaluation results) like user data change, role assignments, etc in a standardized format and uses it to develop a standardized Authorization model across all the relevant products within the enterprise. This approach is similar to the process of periodic synchronization that provisioning product perform to ensure that they have correct data and hence correct user's profile across all the applications.
    At this point I do not know of any commericial or opensource product that can help people achieve this.
  2. Centralized and standardized Runtime (and administration) - In this approach, there is a central/standard runtime policy evaluation engine that can be used by application to perform the authorization. This is an approach that one my client calls "cop-out approach". When comparing with authentication world, it is similar to Web SSO approach where you expect application to change (or it may not change if application container is well integrated) so that at runtime the application will leaverage a standarized approach to make authorization decision. But just like SSO, if your application is in support mode (which most of the money making stable applications are), you probably will not be able to use this. The reason for calling it cop-out is that this approach is basically built on pricipal of "my-way or highway" and that would ensure that most of the application would probably not be able to leaverage this. My pessimism on this comes from the first hand understanding of how few applications have moved to Web SSO platform over long time at most of the clients that I talk to. Most of these are very large clients (with 2000 and more apps) that are running these infrastructure for atleast 4 years and are making slow progress.
    There are 3 commerical vendors that I know of (i.e. BEA, CA, Securent) in this space (2 older companies merged with bigger company) and one standards i.e. XACML that defines the standard protocol for request/response to the centralized service.
  3. Centralized and standardized Administration - In this approach, there is a central administration system which is used for policy design and then it is distributed to external runtime entitlement/authorization system in a format that can be understood by these third party for enforcement at runtime. This is similar to the approach of Identity provisioning, but it is much more difficult to achieve due to a myriad of reason (may be next blog) compare to IDentity provisioning.
    I do not see any of the vendors moving in this direction but would love to hear otherwise.
I think there are a few hybrid models that are possible based on above approaches (and possibly other approaches like audit/log management) but would love to hear your thoughts. At this point, I think things are still unclear as to how the entitlement landspace will grow , what its drivers are going to be or would it even have any drivers to continue (which has been the reason for lack of vendors in this space for so long). This is an interesting and complicated space where it would be fun to watch how the things grow.

Friday, March 03, 2006

Higgins - What is it?

The news sites have been really hot with the Infocard and Higgins after they came in to the spotlight during the RSA conference. To be honest, I did not take a look at the Higgins earlier as it was being described as some sort of trust framework which I thought was really weird since for me trust between system is not technology decision but a human decision. Guess it was mistake on my part to not go beyond the name and look at the technology documentation. Since then the things seems to have changed dramatically and so I finally forced myself to look at it in more details. In this regards, thanks to Phil Becker's article at DigitalID World, I took a short journey of reading through the article at Eclipse and Higgins website.
Higgins
This is a framework API implementation for Identity technology (similar to Java framework APIs like JDBC, JMS, etc) which will allow people to provides plugins to their respective systems (just like database vendors provide JDBC implementations or MOM vendors provide JMS implementation) which can perform the following functions on the specific implementation of the application (like LDAP, Email Server, ERP system, Network Access Control systems, etc) -
  1. Authentication of credentials for access - this means that the framework would provide APIs (guess better than JAAS??) to allow framework users to pass the user identity and password and thus authenticate the user to the framework. So basically the idea being that just to use the services you will have to authenticate at the system level.
  2. Authentication of each facet within the context - which I guess means that any "Higgins" enabled system (i.e. system for which the "plugin" is available) will provide interface to accept the credential provided by the caller through framework and return whether the authentication against that "Higgins" enabled system was successful.
  3. Authorization of access to facet profile data using role-based access control lists - so based on RBAC List (which roles- framework or "Higgins" enabled system??, what granularity of access control, is there are rule based access control, why not MAC) the "authenticated " user (guess authenticated against the framework or "Higgins" Enabled system) would be able to view and edit his or somebody else's Identity data (which will consist of what? - name value data pairs, binary photo, biometric data, medical record??).
  4. Facet search and editing functions - Basically a CRUD +Search functionality for IDentity and associated data (the Creation and Deletion function is not explicitly said to be part of the system, what gives??)
  5. Support for adding tag properties to facets and on the links between facets - what is a tag property? Where is information on link between the facets (identity) stored? Is it something like random schema extension i.e. for example the system supports just User ID, password, comments, homedirectory but even then the "Higgins " enabling of the system would require it to support any generic data which a user would like to associate with the identity of the system (like an account GUID or telephone number). Doesn't this requirement seem to be too wierd or did I get it wrong? Hopefully the framework itself would provide services which "Higgins" enabled system's plugin can leaverage to store the data.
  6. Replication/distribution of context data to Higgins clients - Hmm.. seems close to the idea of data synchronization which is very popular in the provisioning world.
  7. Synchronization of context data - Well I am not sure how the "Higgins" Enabled system can provide such facility. The basic facility would most probably be provided by framework and the system's plugin would need to provide the capability to perform bulk identity data extraction or retrieve incremental changes.
  8. Persistence and encryption of context data - Last but not the least security is important w.r.t. to identity data, but how can we expect legacy systems to provide encryption capabilities. But I am assumming it would be more like an option available if provided by "Higgins" enabled system.
The framework/System/API seems more like a way to develop standardized framework for provisioning system so that the companies like IBM, Novell, Sun, CA in the Enterprise Identity Provisioning market do not have to develop 10,000 connectors for 10,000 applications out there or better still, the provisioning itself would no longer be an integration nightmare. In that sense I see this framework as the next step to provisioning service development which seems to have started with SPML but never really picked up enough steam. But then may be working with enterprise identity implementation for so long has made me look at every thing from that point of view. Hopefully my understanding would be corrected by other bloggers and domain experts as we go along.
Higgins & Infocard
Now lets try to analyze how this framework and Infocard work.
  1. Infocard as I understand is a desktop technology which allows people to manage cards (self-issued or thirdparty issued containing Identity and associated data) on their desktops. So, it seems that the concept of context matches Identity Provider while facet seems to match the concept of card. (Am I trying to over simplify here?). The "Higgins" framework seems something that can be leveraged on both client and server side but assuming it being part of Eclipse (mostly java), it seems it will find home on server side similar to the diagram shown on the website.
  2. I am assuming that people would be able to use the InfoCard interface itself to manage the data that is stored on identity providers website. If this is not the case then, I guess, they will have to go to Identity Provider site to do the same work. Incase of "Higgins" integrated clients (if they are present on desktop), the Clients would be able to use the Higgins framework either on the client side or on server side (invoked through webservice) to perform the same operation. Does that mean Higgins would be the alternative to Microsoft products on server side to get the same job done? Seems like Eric came to same conclusion.
  3. Infocard seems to be a technology on the desktop which will be integrated with Internet Explorer (and may be Firefox and other third party application) to generate the authentication credential for a specific website which will be used by website for authentication. Now this component of being able to generate Token seems to be completely missing from the Higgins (did I miss something??). May be I am being completely naive here but I see some humor in the thought that Higgins a trust framework would not support something similar to WS-Trust :)
So it seems that Infocard and "Higgins" are most likely complementary technologies with infocard taking care of the runtime aspect of authentication while Higgins will mostly be simplifing the management aspect of the Identity (and hopefully the runtime aspect of token generation) for identity providers or user's.

Sunday, January 15, 2006

2006 Prediction - Recap

Seems like the 2006 Prediction season is over and so I thought that I will try to capture the various predictions in Identity Management space that I came across.
  • (Nick at WickID) Host/Mutual authentication will be critical. There will be an attack against banks using non-cryptographic based host authentication (ie, pictures, cookies). - I am assuming that means machine authentication besides user authentication something similar to that from Passmark and Trusted Network Technology. This makes sense and will really be looking forward to various non-intrusive and intrusive technology in this space.
  • Transaction authentication will become a hot topic later in the year due to session hijacking trojans. - I think people like Bruce Schneier have already been talking about this. An important aspect of transaction authentication is that it needs to be pervasive instead of just being limited to online experience. Besides that the technology that would actually help achieve this should be varied i.e. multifactor, multichannel.
  • Strong authentication systems that don't follow Kim Cameron's Laws of Identity will be seen as weak and catch flak for it.
  • 'Layered Authentication' where lack of a cookie or appropriate IP address triggers additional authentication will be shown to be a marketing neologism covering weaknesses. "Layered authentication" based on cryptographic mechanisms to secure session, host/mutual and transaction authentication will get alpha-geek backing, though it is unclear whether that will help adoption of such systems.
  • (Radovan) "Identity" becomes mega-buzzword - I thought it already was with almost 15 implementations that I can count (with help of my friends) with various vendors in US and we are a really small company in east coast.
  • Many "identity" mistakes happen, but it will take a while for them to be seen - Hmm.. this is a good conclusion that you can draw about anything that touches so many aspects of the enterprise for example like what ERP was for Manufacturing Industry. With regards to WS-Trust and SAML, I completely agree.
  • More client-side identity implementations will be seen - I am not sure how the future will evolve but the way I see it, people should not be keeping sensitive data (including their identity information) on their machine (since it is more vulnerable to attack). But at the same time, I am sure vendors will find better ways (like low cost smart cards, network or set-top box extensions or network devices) on the client side to do the job. But at the conceptual level even though I agree that clients should have the right to manage their identity, the actual management of the identity (i.e. implementation) may be left to professionals.
  • Spam, phishing and pharming will get even wilder - Nothing new here.
  • Strong authentication will get integrated with "identity" - I guess I do not understand the difference between authentication and "identity" the way Rodovan sees it. I think that authentication can not exist without identity being in place. So, the companies are getting the idea in various form that they need to improve the authentication but I am not sure whether we will be seening the SecurIDs anytime soon. It is way too costly (initial and ongoing) and time consuming to roll them out and manage their lifecycle unless it can be shared across the industry (which goes back to federated identity, trust, etc) or taken over by govt through standard digital identity system.
  • We will see attacks targeting legacy "trust" mechanisms - Well I think people have succeeded doing it and others have thought about it publicly and vendors are providing the ways which can possibly be exploited (as specified in the discussions) to make this prediction possible.
  • (Mark Dixon) 2006 will bring new methods for more easily implementing Identity Management solutions - Amen!! But would really like to know what are the vendors and consulting firms (I think this may be called IP by some consulting firm) are doing achieve that. Shouldn't the forums like Liberty alliance be used to develop integration patterns and process patterns. The vendors can then develop a feature guide to point how the basic patterns can be implemented and hopefully we can make this prediction a reality. Any other thoughts on how to achieve this!! Will really look forward to discussion on this topic in "enterprise identity" blogosphere.
  • (Jackson Shaw) people will wake up and realize that identity management "is only the aspirin to the headache we have engineered for ourselves. What are we (end-users, companies, ISVs and platform vendors) doing to solve the root cause of that headache - interoperable authentication, authorization and identity protocols? - I am relatively new to this whole world of enterprise computing (just 7 years) and so should be forgiven for talking out-of-you-know-what but I am not sure what this means in the world where the mainframe is still the main workhorse in large businesses and cost of replacing existing systems is astronomical and sometime unthinkable from business point of view. The meta-directories and connectors are the only way to integrate with a lot of these systems. So, I think this headache is something that we have to live with unless somebody is creating a new company from scratch. He will have the similar headache five year down the line. Did I misunderstand something?
  • (CA) 2006 will mark the beginning of a security market shift as various security elements which were once dealt with separately, such as threat and identity management, begin to 'talk to one another' for even tighter security controls - You can already see this happening with available products like Identity Engine and enterprises are already consolidating their monitoring system to track end-to-end Identity flow. In addition to that, I have seen companies expecting the web endpoint devices to support or integrate with the SSO out-of-box besides the other things like SSL endpoint, tcp connection, etc and Vendors like CISCO going deep into the application layer (and I am sure they are going to encounter identity there). So, seems like it is happening.
  • (Eric Norlin)The divide between user-centric and enterprise identity management is the No. 1 conversation in 2006. - Hmm.. user-centric identity, I will wait and watch (unless a big portal like yahoo or google exposes something for others to use) but Liberty jumping into it does makes it interesting.

Wednesday, January 04, 2006

AuthX followup - Request

I am at the moment in talk with Vincent who is part of the AuthX team that is working on developing Authentication Authorization framework/service as part of Apache Directory initiative. Feel free to ping me if you would like to join the discussion on this topic. I sincerely feel that as somebody who are looking at the various trends in IAM industry, we should try to help them get the system right so that it can be leaveraged across the various opensource application. Feel free to leave how you would like to participate (email update, blog post, etc).

Enterprise Identity - Discussion

After James kicked off the discussion on Enterprise Identity, there has been a [cro] lot[Pat Patterson] of[Johannes Ernst] input[Radovan] on the various subject of Enterprise Identity.
I thought that I should also chime in, since some of the thoughts that James has expressed are similar to that I have expressed earlier on provisioning and repository consolidation and wanted to respond to some of points raised.
So, lets take the points one at a time
  • Workflow and MOM/ESB - The basic idea behind this is that most enterprise have workflow system and what they need is a connectors to a few identity repositories. Well, I know of a similar implementation that I was part of and we wanted to do all the way so that we will have a bunch of workflow engines and connectors in each geographical areas each of these connected to each other using MOM (the existing ESB was built over MOM). Now the project failed due to a lot of project management issues (I know how it sounds) and Vendor was brought in to review the design. They told us that we were not using their product like they intended it to be used and got a big rap on that. It is at that point that I realized that the existing provisioning products are like the ERP suites that tried to do all the things by themselves and we will have to wait for next few versions for these vendors to realize that they need to do what they are good at i.e. creating connectors and allow workflow to integrate with their products. Another big issue that I have with the vendors with product design that has no concept of connectors for Groupware, ESB, Email systems which is not exactly a resource.
    Going back to Radovan's contention that where is the workflow engine, I agree that most of the existing Identity Management system were mostly built on Lotus Notes like document based groupware system which can not be called a great workflow engine. BUT the rise of Business Process Management (and existing ticketing systems to some extend) are a good choice for most of the request based Identity Management workflows and provide good architecture for integration with third party systems including identity management systems.
  • Repository Consolidation - I may be preaching to the choir here but just to reiterate when ever a new application is coming on-board the centralized identity access management infrastructure, it has a few options based on what the team managing that infrastructure is ready to provide
    • Use consolidated Repository - This typically represents the enterprise LDAP which can be leaveraged by the applications for authentication and authorization purpose. An important aspect of this is how easy it will be for application to come onboard i.e. will the Repository management team provide adequate interfaces to allow the applications to leaverage the consolidated respository to its maximum (i.e. easy user, group and user to group mapping management with both web based and web service based interfaces).
    • Use consolidated Authentication point - Most of the times, architects are not willing to give access to repository stores or consolidation of repositories is not possible, authentication can be made available in form of Web SSO, Security Token Service (SAML), etc which can be leaveraged to get the work done. Again as before unless there is appropriate and easy application on-boarding, off-boarding and BAU management process is in place, application would not like to integrate with such systems. Or as I heard one application architect told me that "it should be as easy as dropping a jar file and changing a few configuration" (which I guess is a utopia that all cross-concern services want to be at)
    • Use consolidated Administration point - This should be the last option for the applications that fulfill specific criterias like third party, legacy, high volume/performance application (as pointed out by Radovan).
  • Microsoft - After looking at Windows Workflow Foundation, the first thing in my head was more around, web interface to windows workflow design + MIIS = Provisioning Product. I am sure a lot of Window shop would really look forward to similar product instead of going out and purchasing product from other vendors.
  • Policy Directory (assuming that is what James meant) vs Policy Service - I am a bit confused here and I think we may have to go back to same discussion about the Authentication such that may be at the moment an Authorization Service makes sense and later on people can start thinking about Policy Directory. This I think makes more sense because of the basic fact that authentication (even though it was theoretically easier task) has taken us so long, I am not sure when we will really understand the most of the issues around authorization (which I think is much larger nut to crack given its shear size and reach into the application - who wants to make the decision whether something is a business logic or authorization decision)
  • Enterprise DRM/Data Privacy - This is an important thing that I want to throw back at James since he raised the DRM and would like to know everybodies thoughts on the subject. Basically so far Enterprises have solved the issue of Data access using a wide variety of integration systems like ESB, simple ftp, etc and all the bunch of laws requires you to make sure that you know who is accessing the data and doing what with it. Now how do you build a system that allows you to create a right management system which can ensure and track this requirement. How are enterprises solving this issue?

Monday, January 02, 2006

Letter to AuthX team

I came across the AuthX project some days back and read through some of the code and documentation. I will not claim that I have understood the whole project and would request you to feel free to correct my understanding.
Now getting down to the whole idea of AAA, lets me put my understanding of this domain.
  • Frameworks do not work, Services Do: I have spoken to a few architects and in addition to that during the process of various implementations, I have realized that frameworks are really a tough sell. Instead what people are looking for is lousely coupled services. So, there would be an authentication service, a fine grained authorization service, and so on. By the concept of service, I do not mean a SOAP or a REST interface but just a java interface that has method that accept primitive variable types (I like to include strings in this which you may not agree with), to ensure it can easily be exposed using REST, SOAP, RMI or VMPipe Call through the MINA.
  • Authentication Service: The authentication service should be able to support identity and password, certificate (which is a single blob) and additional protocols which take multiple steps to complete (like some token based authentications). So, in such a scenario, the interface design should be able to handle all these scenarios. I would recommend that you look at WS-Trust specification as a good starting point for how you may want to design authentication service i.e. as a token issuance service.
  • Authorization Service: I think you have got the basic idea correctly but there are a few important things that I think are missing from your design like the idea of context of authorization, obligation, additional apis. Lets take the idea of context which typically means additional information which are important to make the authorization decision. For example how will I use the authx system to grant access to a person based on the client IP(i.e. intranet vs extranet). This context information typically will include additional information about user, resource, action and environment (like IP, time of day). Even though you may not support these facilities in 1.0, I would suggest that you develop interface to support this feature. I would also suggest looking at XACML specifications. In addition to that authorization interface must support additional set of APIs besides isAuthorized (or renderdecision in your case). It should be able to return answer to the question of type "give me all the resources that this subject can "read". This is asked time and again by the customers for developing their application (for example drawing menus)
  • Other services: I would recommend that you guys should seriously think about developing "Auditing Service" and "Administration Service".