Identity and Access Management

Understanding IAM Technology: Web SSO Part II - Data Model (Authentication)

2015-09-06T14:12:00.001-05:00

This article is in continuation of the previous article. I started writing this long back but kind of left it mid way as the entire web SSO domain had matured at that time. Due to multiple reasons we have seen new generation of people entering the Web SSO domain. Keeping them in mind, it made sense to revisit this old post and update it with my thoughts and ideas. I do apologize for any inconsistency you may find between my last article and this one (given they were posted 9 years apart).

The core Web SSO functionality are as follows

Identification - Do we know the identity of user who is trying to access the system?
Authentication - Can the user (person/application/service) prove that he/she/it owns the identity?
Authorization - Can the identified and authenticated user perform the specified action (e.g. read) on the resource (e.g. URL /myapp/premium) within the context (e.g. from the given ip address at the specific time of day)
Identity transfer/Federation/Assertion - Ensure that authenticated user can access authorized functionality of any application that is part of SSO/federation security domain without authentication.
Attribute enrichment - Ensure that application that is part of security domain can access additional information about the user (e.g. role, permission, display name) that it is authorized to.
Session management - all the applications that are part of federation must be bound together through a single session that user establishes at the time of first login in the domain and ends by initiating a global logout.
User and Password management (primarily self-registration and self-service) - allow users to register themselves and then manage their identity information and credential information. Even though these are considered to be part of a provisioning solution, most of the stand alone web sso product/services have to support these basic features.

Please note that I am not making any distinction between the old concept of federation and Web SSO since the two concepts are just a technological manifestation of the same underlying process.

The focus of the rest of the article is on authentication, identity transfer/federation and attribute enrichment within the context of authentication/login process.

Any design of the Web SSO solution has to represent the following concept either explicitly or implicitly during the design.

Security Domain

This is the scope in which all the other components exist. Most of the logical concepts of the data model like applications will exist within a particular security domain. Some of the components that represent an architectural component (e.g. a security gateway) may need to exist outside the scope of one security domain.

Application

The application forms the highest level of resource that is typically used to develop authentication and authorization policies. The application has following characteristics

Application is identifiable by a unique identifier within the sso system
The application is typically associated with an architectural component like web server or application server that hosts the application.
Applications also form an important scoping mechanism for delegated administration to allow application specific administrators and developers to be part of on-boarding and management process.

User

User are people, applications and services who need to access an application. They have following characteristics

Users must be uniquely identifiable within a security domain by an identity. In most of the cases, there may be a single attribute like user id or email that uniquely identifies the user but in a federation or multi-domain structure, additional context may be needed to uniquely identify the user (e.g. in case of multi-domain AD setup, user may need to specific their domain).
Users may have one or more attributes (e.g. name) which may be single (e.g. name) or multi-valued (e.g. groups) associated with them. This information may be of interest to application (e.g. display name, groups).

Authentication Method

Authentication method describes the type of authentication credential used for authentication. This is classified based on the authentication factors. Typical authentication methods supported as classified based on authentication factor are as follows

What you know

Password based including API keys and other similar shared secrets

What you have

OTP based (e.g. google authenticator, hardware and software tokens)
Smart Cards
Certificate
Kerberos and other standard and proprietary token based (e.g. JWT)

What you are

Biometric (may be used in addition with other authentication factors)
Adaptive authentication which leverage the user's behaviour and other environmental factors to assert the user details

The Authentication method may or may not be associated with a directory with user information. For example a certificate based authentication process may not have an associated directory since there is no information that needs to be stored for each user trying to authenticate while in case of passwords you would need a directory to store the shared secret.

Authentication Channel/Protocol

Authentication channel refers to the underlying protocol/process used to transfer the authentication credential from user to authentication server (mostly Web SSO). Some of the examples of these authentication channels are

HTTP POST and cookies/HTTP responses - used primarily with password based authentication. Most of the HTTP Post based implementation are based on single round trip (i.e. you submit your password and you get success/failure response) but there are other scenarios (e.g. OTP based) which require multiple round trip. Please note that we are not talking about step-up authentication (see below) here where two authentication methods are combined together on the same channel/protocol. The Form based authentication used by web applications will fall in this category as will custom URL based API authentication models. Please note that due to it's nature (i.e. this method can not be combined with application transaction/operation), this approach has a firm dependency on session management.
HTTP Authorization header - used to transfer passwords (Basic Authentication, Digest, etc) and tokens (like Kerberos, NTLM, JWT, OAuth, etc). Integrated Windows Authentication (SPNEGO) which rules the Microsoft world belongs to this category. Due to it's nature, this approach can be combined with application transaction to remove the explicit authentication step (see above) and associated session management.
HTTPS - besides supporting all the HTTP based authentication channel/protocol, the HTTPS also can support certificate based authentication methods (SSL). Please note that even though not explicitly identified here, it is recommended that all the HTTP channel/protocols described above should use HTTPS to leverage the transport layer security inherent in the protocol.
IPSec and other Networking protocols (like RADIUS, IP Sec, etc) that support password, certificate and other authentication methods through specific authentication protocols (like EAP, MS-CHAP, PAP, etc). This article will not focus on these set of protocols.
SAML used to transfer various types of supported tokens (e.g. user/password, kerberos, etc) from one security domain to another. The transferred token can then be used for asserting an identity within the security domain. Due to complexity of the protocols involved, this is typically associated with a session management.
OAuth including Social logins like Facebook, google, etc that are used to transfer user identity after authentication. Due to complexity of the protocols involved, this is typically associated with a session management.

Many of the authentication channels are associated with specific authentication method (e.g. Certificates are mostly used with SSL). In addition to that same or different authentication channels may be used by different application channels (e.g. Web Application versus Web services/APIs)

Authentication Policy

Authentication Policy defines the process that Web SSO must use to drive the authentication for a given user. This process typically involves the following phases

Identification - an optional step that may collect various information like IP address, user id and other environment details (like browser and os information in case of adaptive authentication) to identify the user and it's context. This information may then be used to decide on the applicable authentication policy for the user.
Authentication - based on various factors like user's IP address, user id, etc, the system identifies the authentication method and authentication protocol. For example based on the user's IP address, Web SSO may trigger Kerberos over IWA for intranet and form based (HTTP Post) login process for internet. Similarly based on the identified information and associated risk analysis (e.g. user's is access web app from a new location), the policy may require multi-factor authentication for the user. Each authentication process may have additional policies (e.g. password expiry policy) which may trigger different result for the authentication besides success and failure.
Please note that authentication process may involve one or more steps. The steps are a combination of authentication methods, associated authentication channel and configured directory (if applicable). Most of these authentication "steps" must be sequential or appropriately prioritized to ensure that the final response is always the same. Some of the methods used are

Sequence based - each step is tried in a predefined sequence until a success is encountered.
Weight based - the step may have associated control flags of required, sufficient, optional, etc which determine the weight of the result from the step in final determination.
Policy based - a complex policy language may be used to determine whether the step is applicable in a particular scenario (see example about IP address used for IWA or form).
A combination of above may be available to ensure that final response is predictable.

Identity Mapping - Even though most of the time the identity authenticated would be known to the security domain, we still need to call out this step to ensure that model is extensible. Some of the example where the identity mapping comes in to play are

Federation - In some cases where the user identity mapping may be many to one OR one to many (i.e. all the users of a given vendor should use vendor id to access system OR depending on the specific role user wants to activate user may get different identity in the service provider), identity mapping has to be done by web sso product
Federation - Users may want to attach their existing user id on a website with their facebook or google user id as part of new login feature rollout. In such scenario you need to maintain an explicit mapping between the two.
Authentication - In specific use-cases like Kerberos or certificate, the user identity are provided as an AD user id (e.g. domain\user) or certificate DN. This would typically be mapped to a security domain user id before further processing can be done.

Attribute enrichment - involves collection of various attribute and values (single or multivalued) from various directory based on the identity (with or without additional directory specific mapping). These attributes may be collected as part of initial profile establishment or just in time for identity transfer to specific application.
Audit - may not be a separate step but part of each and every phase of authentication process.
Session establishment - may involve storage of various information (like login time for hard or idle timeouts) either as tokens or in local or distributed storage with unique identifiers (called session id). These session id may then be associated with application session id when the application is accessed first time. This information may be used by applications, authorization engine, session lifecycle management engines (that may enforce session timeouts, user to session mapping policies) for enforcing various associated policies. Any Web SSO system that supports a concept of session typically also has a concept of logout which is expected to disassociate the application sessions from authenticated session and destroy any information stored in authenticated session.

After the initial authentication process is completed, other aspect like authorization and application specific identity migration may get triggered.

Summary

Any Web SSO that wants to implement the authentication capabilities must design for the various items identified above to ensure that they are not constraint as they enhance the system over time. It is important to distinguish the idea of directory (data store), authentication method and authentication channel within the Web SSO to ensure that you are not restricted by potential new requirements (e.g. handling new tokens, authentication channel that require multiple round trips) as you try to enhance the product/service beyond basic password and social login use-cases.

Reclaiming your account: Password Reset/Forgot Password

2009-09-15T04:32:00.001-05:00

This is probably one of the oldest functionality that is part of any password based system and by now I was hoping that people will have figured out most of the ways of doing it. But while reading answers on stackoverflow on this topic, I was impressed by new ways being developed and implemented by developers in wild. While reading the discussion I felt that there is lack of a structure to look and study this functionality and this post is an attempt to define a structure.
Before I go there, I wanted to capture my understanding of the password reset functionality.

Why - Well if we are not noting down all the accounts we have created in life (either electronically or manually), it is possible that we are going to forget passwords for some accounts as we age. Even if you follow some techniques like having standard passwords across all your accounts, due to site limitations, change in word preferences, etc, you may not remember the applicable password for a site and so the lifesaver

Why Not create a new account -

a lot may be associated with that account in-terms of your reputation, information, etc
site limitations of being able to associate a personal identifiers (may be email address or bank account number) with only one account
the account id may be generated and can not be changed during your association with the site (SSN, biometric?).

What - Password reset/forgot password is a functionality (a bit different from change password - where you remember/know your password) by which user or someone else on behalf of user is able to change the password without presenting their existing password. Again even though the discussion would focus on password, it would probably apply to any shared secret between user and identity provider

How - As discussed earlier, the password reset can be done by user or somebody on their behalf. This process typically involves

Verifying the requester's identity
Ensuring that requester is authorized to request password reset (incase requester is same as owner of account, this check may be moot)
choose a new password (either generated or accepted from requester subject to fulfillment of password policy)
provision the password into the authentication system
notification that new password can be used, if out of band password change happens (and possible security notification to account owner that password has been changed)

This post explores the first part of the process i.e. verifying requester's identity

Classification Approach

Based on the basics of authentication process, we know that we can verify user based on something they know, have or are. Now in order for the authentication to work we need to ensure same information is available to user and Identity Provider at the time of verification. This implies that prior to verification there has to be an acquisition process which can be classified based on when (at registration, during usage of account or out-of-idp/user account relationship) and from whom (user, Identity/service provider, third-party like credit rating agency, public data) the acquisition has been made.
The verification process itself can be classified based on the type of shared secret/credential along with other criteria like verification channel.

Example

Based on this we can try to classify an approach for user verification which has been done for some of the most commonly used approaches. Please note that this is not an exhaustive list of various approaches in wild and just tries to show how the classification can work for some of the approaches being used in wild

Verification Approach	Acquisition						Verification
	When			From Whom			Type			Channel
	Registration	Account Usage	Out-of-band	User	Service Provider	Third Party	Know	Have	Are	Single	Multi
What is your pet's name	Y			Y			Y			Y
When was your last withdrawal from account XXX?		Y			Y		Y			Y
Did you live at ZZZ on DD/MM/YYY?			Y			Y	Y			Y
Please provide your date of opening the credit card account			Y		Y		Y			Y
Send a nounce+ to Email Address *	Y			Y				Y		Y
Send a nounce to Cellphone *	Y			Y				Y			Y
One time Password cards for specific duration			Y		Y	Y ^		Y		Y

* The classification may change depending upon the implementation but you get the idea.
^ If IdP is different from Service Provider
+ I do not want to use "temporary password" as it can be confusing

At present not all the permutation/combinations may be utilized but we may find other ways to combine these factors to create new methods. In addition to that, I have a feeling, we would figure out lot more ways of classification of the password reset process.

Why

Even though this was just a thought exercise, I think we may be able to use it to study and compare various verification techniques. Given that people are already treating some combination of authentication/verification techniques as multi-factor (even though theoretically they may be single factor), it may make sense to develop more detailed classification technique so that we can compare various "multi-factor" techniques and ensure that we are not using pseudo-"multi-factor" techniques. Based on my limited knowledge, I have not run into any such framework but would really appreciate pointer in such direction.

Thoughts?

Tashan and Data Loss Prevention

2008-05-10T22:53:00.001-05:00

I never thought that I would use the two in same blog entry. But I really liked one of subplots of the movie which revolved around usage of social engineering to extract sensitive information about HNI from a Call Center employee for extortion purpose (well a good usecase for DLP). Again given that there are existing products in DLP space to prevent the same from happening over network, would it make sense to add the same to the voice channel too?
The quality of voice recognition (esp for numbers) technology is pretty high. This is pretty evident from the number of deployments in multi-level IVR menus. But , I think, the voice recognition capability of these IVR system is high because it is based on the premise that the user wants its voice to be recognized and false positives for these systems are probably still pretty high.
Incase of DLP, I think, the basic idea is to control accidental release of information and some simple data theft scenario. So, from that perspective adding Voice recognition to DLP makes sense esp for call center deployments.

On a personal note

2008-02-17T06:35:00.001-06:00

It has been a while since I last posted on this blog. In the mean while, I have moved back to my home country India and have settled in Pune. Even though I continue to be in the Identity and Access Management domain, my role has changed a bit where I would be focusing on scaling out the IAM practice instead of working with clients on daily basis. At the same time to keep my skills fresh, I will be working on selected projects because there is nothing like talking and working with clients in trenches to be at the cutting edge (already have done one tour of duty and learned a lot about portals in retail banking while working on a authorization policy model for multiple retail banks).
I would be looking forward to continue sharing with you all some of my experiences and thoughts in IAM space on this blog. I will be resurrecting my other blog which will concentrate on my life in India and other issues that I want to talk about.

Cisco Acquires Securent

2007-11-02T06:56:00.000-05:00

Why? Many people [Burton group] who [Ian Glazer] are[Jackson Shaw] more[Dave Kearns] qualified[Forrester] than[Ian Yip] me have expressed their opinion on this subject. The main reason for the acquisition proposed -

Cisco has finally seen the light and decided to enter the IAM space - I do not think this makes much sense given that they are not a software stack company, not even a software infrastructure company (like Symantec, Oracle, SAP, etc).
Cisco needed a product to build identity based authorization into network and hence all its products - I think it is a result of reading too much by us entitlement management guys in to it and the way we would like to see the world.

Externalization of Security Reading in to the fact that product has been placed in Collaboration Service Group and created a separate policy group, it looks like Cisco sees the product as a quick way to externalize the policy management from the various collaborative products. Another important aspect of these product (esp SaaS) is that security for these product is managed by End-users. Most of the web based application vendors (who do not sell security products) have been able to successfully externalize the authentication (support for sso, saml) and user repository (LDAP) but do not have a good model to replicate in the authorization space. If the result of this externalization of authorization across multiple application is successful, vendors will have a model to replicate. This will be a very big win for various enterprises that have been trying to drill this into vendor's head (James McGovern being one of them). But I think this is a tougher problem to solve than externalization of authentication and user repository (which are mostly one time job). I see the following problems

If externalization is being performed at administration level, then how do you expose widely different access control model (a SaaS site's model would probably be very different from Web Conferencing / IP Phones access model) through same interface without sacrificing usability, flexibility and asking users to learn a new policy language.
If standardization/externalization is being performed at evaluation level, then how do you meet different performance requirements of different access control models through same generic engine. In addition to that keeping different implementations (on different platforms) for same policy evaluation algorithm with various performance tweaks can be tough.

Impressive Team and great execution I am amazed by how everybody has seen it as a complete technology acquisition and has not given enough credit to Cisco for investing into the team (may be they know something that I do not know about how acquisitions work). The complete team starting from Rajiv Gupta to their pre-sales team members have time and again been giving pretty impressive performance during various meetings with their (potential) clients. In addition to that if any body has been tracking securent over past 1.5-2 years, it is amazing how their sales and marketing team (biz dev) have taken a "would-be" space of authorization to a happening space and recreated a whole domain of entitlement management so much so that this year can aptly be said to be year of entitlement management atleast in terms of hype that was generated (I have never seen so many people clamoring to jump on to third-party entitlement bandwagon in financial services). I would really love to see this team take on a bigger challenges like Salesforce :) To me that could be a great reason in itself to buy the company instead of OEMing the product (beside the obvious reason that there is always the issue of OEMing from a small vendor which may be gone or bought by a competitor). What Next? Well looks like Securent is getting ready to be subsumed by Cisco and hopefully, in a year or two, we would have somebody from their team coming to burton group conference (or some other entitlement confrence) to discuss how their attempt to externalize the security from their collaboration software went and we all will have a good use-case to learn from. With the economy in US having a few hiccups and a possibility that SOX (one of the primary driver for various iam initiatives at this point) may be blamed for all economic problems, the info sec across the enterprises may be fighting a tough battle to get their company's entitlements in order (as soon as they get their user directory, authentication, provisioning in order). In addition to that the big vendors are expected to come out with new offerings in this domain which would make survival of new and existing company tougher. So, will we see a new startup in fine grain authorization space? I sincerely hope so and would love to see them grow and find a new niche in this space because as I see it the problems have just become tougher to solve.

Roles - What 'bout it?

2007-09-05T19:08:00.001-05:00

Disclaimer - I have not worked on role-mining project and so most of the views expressed here are based on very limited understanding, a lot of arm chair thinking and some understanding of access management. I may be slightly biased against the role-management because I seem the end goal as Access Management and not role management and so far I have not had the "aha" moment for Role Management.

Coming from fine-grained access management background, I have always considered roles as a means to achieve the end goal of access management. Roles to me are an abstraction that we use to separate the policy modeling phase (roles being used to design policy model) and policy management phase (by managing user to role assignment).
But a lot of people do see the roles themselves as something important that need to be "mined" out of privileges. This could be, to some extent, a result of role-centric security model pushed by J2EE specification in past (and now through SCA Policy Framework) and the developers being comfortable with such models which tried to build a simple security model built around the idea of Is User In Role. Even though this works for most of the simplistic use-cases, some of the security model are more complex and that may warrants the need for XACML profile for J2EE to express the security policy to be enforced.

But there is another dimension to this whole discussion. There is a neat idea of Business Role and IT Role (equivalent to Basic Roles in NIST RBAC?) that seems to be gaining ground. The business roles are typically something that are defined by the Business/Organization (like Vice President, Teller, Trader, Foreman, etc) and IT Roles are defined by the application (like admin, user, auditor, etc). Most of the time it is expected that mapping the business roles to IT Roles would simplify the policy modeling and management. This could be a good justification for finding business roles (probably using top-down approach) and "mining" IT Roles (probably using bottom-up approach), if not already present, and mapping the two. So the problem of managing all the user-role relationships can be reduced to controlling user assignment to Business Roles which is something that is already in place in form of HR systems in many enterprise (Again it is probably already showing why I should not talk about things I do not have experience with and so feel free to correct my understanding)
Even though this approach looks great on paper, I am not sure how effective it is. In the few domains that I have worked, most of the business roles are contextual (for example - trader on a desk, teller at a bank branch). I have always thought that some of domains like manufacturing and retailing were closer to a standard role based entitlement model because of very well defined processes and role. But thinking more about it, even those may have nuances like supervisor of a specific shop. Similarly most of the IT roles are also context based. For example an admin role in a account management application would probably be given on specific accounts.
At the same time there are definitely applications ( for example any vice president can approve expense report ; show the admin menu only to an administrator) that can be fulfilled by generic roles.
Ultimately the use of NIST RBAC in an application boils down to how complex the role context is within the domain. In case the context is simple enough, it can addressed by building it in to roles so that you may have na_sales_mgr, emea_sales_mgr and so on. But most of us already know that such hacks, if not controlled, can become a recipe for role explosion and would ensure that you need a role management product.
The complexity of the context itself can make the role almost a secondary concept. For example let's take a case of a consulting firm working on large project. Such a project may have separate teams of developers, architects, infra guys spread over multiple geographical locations. Now such a scenario may be uncommon in IT consulting but I think some thing similar would be case in a auditing or investment banking where some of the multi-national M&A deals and company auditing take place. In the example earlier let's say the employee John Doe is assigned role DBA for the developer teams in New york and Seattle for the project Big Bang and Backup DBA for the architect teams in Europe (located in London and Paris) for the project Solve World Hunger. In this example the role itself is such a tiny part of the possible complex context structure (Location hierarchy, teams, etc). Now there may not be that many examples out there with such complexity at the context but at the same time such examples help keeping things in perspective.

To summarize I think we need to be clear about what is the problem we are trying to solve before starting on the role management path. If the end goal is access management then NIST RBAC should be looked at just one of the ways of policy modeling. But if the goal is to get the organizational hierarchy in control, then using a role mining tool to get some roles that are meaningless to business may not be right way to proceed and instead appropriate process must be defined and implemented for organizational hierarchy leaving the IT Roles out of scope.

Preferences and Entitlements

2007-08-29T21:09:00.001-05:00

So far I have thought about the Preferences and Entitlements as two separate notions that are not connected to each other. But today while thinking about a few things from work and some blog posts, I realized that there is more to the it than that meets the eye.
Before we go any further let's summarize the definition of terms for the purpose of this discussion

Preference is information that user makes available to resource / application to allow the resource /application to present information in a "user-friendly" manner. (I understand that this is very limited version of preference and there might be other better terms like Persona to describe the same concepts).

Entitlement Model (including model and data) is information that resource / application owner makes available to resource / application so that it can present information that user has access to.

Even though these definitions are not the standard, they are used here to drive the point of view that I am trying to explain. At some level we can view these two things as being about the same thing i.e. annotation of the user-resource mapping / relationship. There are a few implications that I could think of

Entitlement Modeling as preference source and vise versa - One of the various source for the user preferences that an application can have is Entitlement Model. For example [James McGovern - Relationships and Authorization] - In case the Insurance application has modeled user's preferences (including relationships and their access levels /roles) in to its entitlement model, his preferences should be taken into account while determining the access for the user's son.
One way relationship (do we have a word for these things) - If we treat the relationships as preference (i.e. I prefer to call John Doe my friend even though he may prefer to consider me to be an acquaintance) and have a standard way to integrate preferences into entitlement model, relationships can be just another preference that is supported by the entitlement model. Please note that incase preferences are modeled as attributes, downgrading relationships to attributes is something that can come back to bite when there are specific requirements wrt relationships.
Provisioning - As discussed as part of entitlement and provisioning integration topic earlier, user's attributes for a given application can be based on the entitlement model the application enforces. Now one of the aspect of this is that some of the attributes /relationships being exported by entitlement model to provisioning model can be part of the self-service workflow to be managed as user preference.
Extending Social Graphs - The relationships and attributes that form part of the identity provider trove, can be further enriched by providing additional preferences or refine the scope of relationships based on resources. For example I can be friend of a person in the context of specific resource (say flickr) but an acquaintance in the context of other resource.

Thoughts?

Integration of Authorization/Entitlement Management products with Provisioning Products

2007-07-14T06:27:00.001-05:00

As part of the various discussions that I keep having in the fine-grained authorization domain (or is it entitlement management now?), this is one of the topics that we visit. The above requirement stems from the fact that Provisioning Products were never built to support the entitlement/authorization concepts and authorization policy lifecycle management.

So, the entitlement management products' management interface (for policy lifecycle management) can not be replaced by provisioning product. In light of this realization, the next step is to find the best way to bring together the two technologies. There are various ways in which the two products can be integrated and some of the approaches are discussed below. Please note that this list is in no way complete and would look forward to your comments on other possible approach in this area.

User Provisioning - The entitlement management product itself may be seen as another repository of user data that must be updated OR the product may be seen as something that must be updated as part of user provisioning for a specific application (which is protected by entitlement management product). This idea is valid only if the entitlement management product can not integrate with standard identity repositories OR due to implementation requirements which forces the product to store the user information instead of pulling it at management and runtime from external repositories.
Incase the product is being treated as another repository of user identity, the User Identity with its standard attributes and roles may be provisioned to the product as part of standard user setup or when the user is assigned an application that depends on the entitlement management product for entitlement management. If the setting up of user information in entitlement product is being treated as one of the steps of application provisioning, then an application specific profile (with application specific identity, attributes and roles) can be provisioned to the entitlement product as part of application provisioning process. This profile would need to be generated manually based on application policy model (see fine-grained authorization provisioning below).
Resource Provisioning - The concept of resource in most of the user provisioning system is limited to the idea of application, i.e. these product do not understand that the application itself consists of additional resources like accounts, documents, trades to which the entitlement provisioning need to happen. Due to this deficiency the user provisioning products are not great for managing and provisioning resources (which most people still think is in the domain of application unless there is a drive to start building a standardized resource lifecycle management infrastructure which may makes some sense for some type of data like Personal Identifiable Information, Intellectual property, etc). But some product may provide the capability to provision the application to the entitlement management product when the application is created in the provisioning product.
Fine grained Authorization Provisioning - The provisioning systems so far have supported the idea of provisioning of user data (id, roles/groups, attributes) into the application repository. People have extended this idea and implemented ad-hoc models of provisioning entitlements into their applications by mapping the user specific entitlement data to standard concepts like application specific attributes (some of the products do not support the concept of role/group as a separate concept). But such an approach means that the model hard coded into provisioning products is completely dissociated from model embedded into the application or the entitlement management product.

As far as I can see, there is no standard way to communicate this information to the provisioning product at runtime. What we need is a way to ask the entitlement management product, what is the model that it wants to expose to the requestor and what is the information corresponding to the model that should be provided to requestor so that they can choose the entilement that needs to be provisioned for OR this information can be communicated to the provisioning system by the entitlement management system as and when the policy model is updated. For example if the authorization model implemented for application X is User based ACL, then the provisioning system would need to display to the requestor the resources (provided by application or entitlement management product) that provisioned user may be granted access to OR incase the authorization model is a role based access control model, the requestor would be provided with a list of application specific roles (provided by entitlement management product) that user can be provisioned for OR if the entitlement model is attribute and role based, the application specific attribute and role list can be provided to the requestor to allow them to define the user's entitlement for the application.
The approach described above is more of a thought and I do not have answers for all the question this may raise. But from lifecycle perspective, unless there is a change in the authorization model for the application(i.e. from User ACL to RBAC), only the attributes and roles (or resource values incase of User based ACL) would change for an application over time and that can be addressed by adding validation and associated remediation to the provisioning system's identity data synchronization/auditing process for the application.

Thoughts?

New kid on the authorization block

2007-07-02T14:15:00.001-05:00

I just ran into a new company JResearch Software which is approaching the authorization from the application developer's angle. Their approach is closer to the acegi model but is better geared for an enterprise.

The whole thing looks pretty promising and could be something that can become more interesting if they go for an opensource model (which should be a big market differentiator) for atleast the core components and start thinking about XACML :)

Food for thought

2007-06-11T06:58:00.001-05:00

Rise of centralized password management and dispension system - With the rise of centralized password management and dispension systems (like Cyber-ark Enterprise Password Vault, Symark Powerkeeper do we need to rethink how the applications handle password storage and operations (like saving password as clear or some reading password from a file for the SSL keys). Obviously the idea is that after people have taken care of standard passwords for their systems, they would like to integrate the applications to leaverage password storage and dispension.
Enterprise Rights Management on Fine grained authorization management and XACML - I have not heard anybody talking about it (may be I am not looking in right place) but isn't it odd that two systems that seem to do the same thing (except the ERM seems to be more of an PEP implementation which also has PDP aspect to it). So, it would be interesting to see how ERM can play well with Fine-grained authorization and XACML.

AAAA and A in Service World

2007-03-25T21:40:00.001-05:00

There are two aspects of Authentication, Authorization, Auditing in the services world. The first aspect (and probably the more difficult from implementation perspective) is integration of the AAA as a cross cutting pattern in to the container, middleware (ESB, MOM, etc), etc to take it out of the service functionality itself and the other being development of AAA &A as service. The first half at this point is an integration nightmare due to no standards available or inadequate standards (like JAAS) or lack of vendors initiatives (like XACML, WS-Trust, Liberty ID-WSF Authentication service) due to either ignorance or no push from clients. I know it is a generalization of the current state but that is not what I would like to cover.

On the service side, the Authentication, Authorization, Auditing, Attribute (and role) and Administrative capabilities have been built into the infrastructure but very few have been deploying it as a service. I think that deploying authentication (RADIUS, TACACS+, etc) and auditing(SNMP, syslog, etc) as a service is pretty well understood. But I do not know of such implementations in case of authorization or attribute. The post [James McGovern] seems to point to fact that AAAA&A in the "SOA" world may need to be better defined and there may be possibility to define their capabilities in a more general way than currently available in the literature.

This post is a dump of my thoughts based on what I have seen others do and how I think people could build services out of their infrastructure components. This attempt to put down my understanding is by no means complete and does not delve into implementation issues. It is a very high level overview which I would like to build on as I gather better understanding of such implementations. The basic approach that I have used to understand the requirements in service world is that a service will consists of

protocols (and middleware) it supports to allow clients to access the
functionality it provides

Authentication

The basic functionality of the authentication is well discussed and is about identifying user (person, organization, entity, process) and validating that it and the authenticating entity know about the same secret (credential, shared secret, key pair, ...).

Functionality

The following functionality would probably be provided by these authenticated service.

Single and Multi-factor Authentication using multiple protocols and repositories (Database, LDAP, SecurID, Kerberos, RADIUS) - In a way the authentication service is a "virtual directory" like interface for authentication into many repositories that support multiple access protocols.
Identity/Credential/Token Mapping - This seems to be a good functionality to have with so many products out there that support different types of tokens.
Token Validation - The basic idea being that once the token has been created, it needs to be validated by each service container and then appropriate subject information can be made available to the service functionality.
Auditing - This is an obvious one. You would probably want to know who authenticated when for what service using which authentication mode and what was the result. Now all the information may not be available for each of the supported authentication modes due to limitation of protocol itself and would need to be dealt with. In addition to that incase authentication process triggered any other events (like account lockouts, session establishment, etc), it would be good to have that information also captured.
Session Management - This is something I am not sure about. The session as a separate service may be something that may be interesting from many perspective (like tracking information about state of user across multiple services and share information between them) but I do not know of any initiative in the industry to standardize that (which may be the case of my ignorance more than anything else). In addition to that most of the standards (like federation) typically build some level of session management into their protocols.

Protocol (& Middleware) Supported

Now based on the most of the common protocols in use today, the following would probably have to be supported by such an authentication service.

Browser Profiles (Cookie based) - This is a good way to simplify authentication for anybody who would like to connect to various browser based interfaces (including AJAX services). But one of the issue that I see is that most of the web sso implementations in past were not implemented with this architecture in mind. They were mostly based on idea of authentication service being embedded in the enforcement point and so it may be tough for some of these implementations to leverage the authentication service in this mode. This would typically involve the typical ID/Password, URL based Ids, SPNEGO, PKI based, biometric and new Risk based strong authentication techniques.
Browser and Web-service Profiles for Federated authentication - This is important for support of the various federated authentications like SAML, WS-Federation.
LDAP based authentication - Given that this is probably one of the most widely supported authentication protocol by third-party software, it may be good to have the service support it.
Kerberos based authentication - There are a lot of third party products and organizations that built SSO infrastructure over Kerberos which was probably the first SSO technology.
WS - Trust - Since this is the most widely accepted Token mapping protocol, it would be good to have this. Now one of the things that I am not clear is whether this protocol can support identity mapping itself (even though I remember some of the federation products leveraging this protocol to do that) as part of standard itself.
Liberty Identity Mapping Service - I am not sure how widely used this one is but may be worth having from the point of view that many telecom providers (esp in wireless market) are building services based on Liberty alliance.

With regards to many of the new protocol standards, the level of interoperability is still questionable but hopefully this will get better time.

Authorization/Access Control

Building the authorization functionality as a service is something I am not sure about. Even though I have seen people build really successful services (for example Disney), it is always questionable how well such a service will work under high performance requirements. In addition to that I do not see access control as a loosely coupled service which seems to be one of the guiding principles of "SOA" world. Anyway, having this functionality as service allows multiple applications (oops I mean services) to share same infrastructure, gives management and auditors(?) some peace of mind with regards to controllability (but that is not completely possible unless the PEP itself is centrally controlled).

Functionality

The following functionality would probably be good to have in such a service

Basic Authorization - Basically the service must be able to answer the question
- Can the user U perform the action A on the given resource R in the environment/context E(location, time, transaction data)?
- What are the resources on which the user U can perform the action A in the environment/context E?
- What are the actions that the user U can perform on the resource R in the environment/context E?
- Who can perform the action A on the resource R in the environment/context E?
Relationship-based Authorization - This covers the queries where the authorization itself is dependent upon an existing relationship between the various entities. For example
- Can two Users perform the action A on the resource R in the environment/context E. For example in case of financial industry where the Chinese wall policy dictates that an investment banking employee can not talk to equities or research analyst, it is required that before two persons can join a chat room the system must evaluate whether the User X can perform join the chat room Z given there are other users A,B,C?
Auditing - Another obvious one to capture. It would involve auditing who tried to perform what action on which resource at what time and under what context and what was the result.
Business Policy translation - The service must be able to consume business policy and convert it in to the runtime policy for enforcement. Most of the current product are not able to fulfill this functionality and can only consume a policy based on pre-configured data model. This implies that policy lifecycle management is not user friendly and is prone to errors (due to the user interpretation involved).
Delegation - The service must ensure that it can support delegation as a first hand concept and use it.

Protocol Supported

XACML - right now this protocol seems to be the only game in the town. It does not provide any thing beyond basic request/response and policy definition model. For example most of the authorization queries specified above are currently not supported. The supported policy constructs is also very limited (for example AFAIK separation of duty concept is not defined by the policy) and hopefully that will improve as we go further.
Others - Given that academia has moved to XACML (and is extending it as needed) as the default policy language, there is not many new policy language in works. There are a few interesting ones like SecPAL and Cassandra (which seems to be predecessor of SecPAL) which are in labs and with a uncertain future.

Auditing

The auditing service is basically an attempt to provide a central service to allow the various services to send their audit events so that a separate infrastructure is not needed to collect the audit information from each service which may be writing to a local file system. Even though the audit systems are mostly designed as passive acceptor of data, it may be possible to develop more active auditing systems which may perform event correlation in real-time against the usage policy and use the auditing channel itself to flag an alert back to the service (along with other people) and thus manage the quality of service. This is not a traditional role of auditing channel and it may be better to let other service provide this capability.

Functionality

The basic functionality that needs to be provided by auditing service

Audit Data Storage - This is the basic functionality that auditing needs to be provided.
Data integrity and availability - This is probably an important aspect of auditing system which is important from reporting perspective.
Reporting - Though not a required functionality (given that there are existing reporting products out there), it is a nice to have.
Analytics & Monitoring - This may be an important functionality to built into auditing service or as separate service which can be used by auditing service if being used in active mode.
User Session Event Flow - Auditing service may provide a way to trace an event or user session flow in real time and get the appropriate people involved as needed.

Protocols

Only standard protocols that I know of in this space are Syslog, SNMP and WS -Management. But other aspect of the protocol which seems to be missing is the standardization of the event data format. I do not know of any standards or initiative to standardize the format/content of the security events generated by various components for easy correlation in terms of event and session flow.

Attribute, Role and Relationship (Identity Data Service)

This service is typically not part of standard AAA&A model but with growing interest in controling and managing the identity data in a more formal way, this could be a good service to have to provide interface for the various types of identity data for employees, clients (persons and organization) and their roles, relationships which are of interest. At some places I have seen this being developed more for business of CRM and HR but hopefully these services would be built in a manner which will allow people to leaverage them across the firm in an identity centric way.

Functionality

As of now I do not complete understand the scope and functionality this service may provide but these are a few thoughts.

User Data - This basically means that for the given identity give me the specified attributes.
Data Assertions - This service ensure that instead of providing the raw data about an identity, the system must provide response to the specific queries that service has to fulfill its functionality. For example instead of providing the age of the user, the Identity data service would respond to the query "Is the user over age of 18?" with yes or no. In order to do so, the service may need to be able to consume CARML properties and correlate it to appropriate user data and rules for evaluation.
Personal Identifiable Information Access Check - This is an obvious one in terms of making sure that services get access to only the specific information that they need so that the unix login service does not have access to the SSN unless there is a specific need for that. This woudl require that the service be able to consume AAPML documents and use it to perform access check. But it may be better to perform the access check in the authorization service and then enforce the decision so as not to duplicate the functionality.
Roles - So far I have not seen much discussion on developing a role service. Most of the role management product do help in creating roles and managing the users assignment to these roles. But the basic problem of delivering this information to the application for runtime consumption is either left up to the web SSO, authorization product, shared repository (like directory or database) or even provisioned to the application itself.
Contextual/Parameterized Roles (relationship) - The contextual/parameterized roles are the role that a user has in a specific context. For example a user D can have "doctor" role in the context of User X while have "patient" role in the context of User DR. Relationships are contextual roles in which the context is one or more user(s).

Protocols

I do not know of any standard which supports the roles (basic and contextual) as first hand entities. The following protocols could be supported by such a service

SAML
Liberty ID-WSF Interaction Service
CARML

Administration

The administration service is a cross cutting concern that affects all the above service inthe sense that each of these have an administration component. The administration service is big enough to be dealt separately in next post.

Federated Authorization and Relationship

2006-12-12T04:43:00.000-06:00

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.

Entitlement Management - What are we trying to solve?

2006-11-23T11:48:00.000-06:00

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

New Applications are good candidate for the new platform (SOA anyone?)
Application that have hit wall w.r.t. entitlements and are themselves looking out at vendors to solve their problems
Applications with new audit requirements may be another good candidate for the platform.
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.

Representing Authorization Model

2006-08-26T22:24:00.000-05:00

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

Users and their organization into groups, roles, client organization, etc
Resources and their organization into hierarchy, groups, etc
Actions and probably some form of their organization
Attributes of the user, resources (and may be actions), environment that help perform fine grained evaluation
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

Manageability requirements
Data location and synchronization
Authorization Queries that need to be fulfilled now and in future
flexibility required in the future
performance of vendor functionality being used
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?

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

2006-08-19T06:52:00.000-05:00

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

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.
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.
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.
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.
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.
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.
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.
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.
Self-service for identity (Runtime)

Summary - User that needs update his information into or un-register themselves from the Web SSO system
Pre-requisite - User has an active session with Web SSO system and the system provides the capability of self-service
Actor - User
Main Success Scenario -

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.
User can choose to update its information in Web SSO or provide his preference to unregister from the Web SSO service.
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.
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.

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.

Identity Synchronization (Administration)

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
Pre-requisite - Web SSO already has the user account for the corresponding user.
Actor - Provisioning System
Main Success Scenario -

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
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.
The information may be removed or tagged to be removed from the system.

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.

User Centric Identity: MY Take

2006-06-30T08:15:00.000-05:00

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.

User Centricity of a relationship and protocol

2006-06-18T15:35:00.000-05:00

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.

User having some level of control what they need to disclose to existing or new acknowledging entity [User-Ack]
User have some level of control on what information acknowledging entity can receive about them from 3rd entities. [3rd-Ack]
User have some level of control on what information acknowledging entity can give to 3rd entities [Ack-3rd]
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?

User Identity: Relationships and Trust

2006-06-15T20:12:00.000-05:00

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.

Take control of your Authentication (and Authorization/Entitlements)

2006-04-13T00:00:00.000-05:00

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 -

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

Higgins - What is it?

2006-03-03T10:27:00.000-06:00

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

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

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

2006 Prediction - Recap

2006-01-15T18:55:00.000-06:00

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.

AuthX followup - Request

2006-01-04T13:16:00.000-06:00

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

2006-01-04T11:29:00.000-06:00

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?

Letter to AuthX team

2006-01-02T19:38:00.000-06:00

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

XACML : Where are you!!

2006-01-02T15:47:00.000-06:00

I do not like writing two blog entries in one day because writing each entry is very gruesome task for me (because for some reason what should be a simple memory/thought dump becomes 1 hr multi-review process to ensure my dump does not stink :) ). But, after running in to entry from James McGovern on my favourite subject of fine grained access control, I think I will write another dump.
The basic point being raised in the article are

What about XACML ? A question for Vendors and Analysts.
Implementation Patterns for opensource - Authorization Provider and Role Mappers with central management (just like an cross-cutting service in an enterprise - My addition to James' thought)
end-to-end (including database) Identity tracking (if I have understood the requirements properly)

I will try to put down my understanding on these subjects.

What about XACML? - Well it seems like people like James (and other enterprise architects that I have met in other financial institutions) and vendors like Securent (I have interacted with these guys and I think they "get it") are keeping the XACML alive. Most of the enterprise groups that are looking for fine grained access control products expect basic implementation of XACML and expect vendor assurance on this subject. This is forcing the vendors to comeup with good analysis of XACML w.r.t. to the things that are misssing from the XACML specification (like authorization delegation). This information can be used by enterprise to force these vendors to get together and sort out the details for these sections. As long as enterprise keep their pressure and show interest, XACML will continue to grow.
Besides that, like James has described for opensource, another policy that I have seen Architect follow is to make sure that new products that they run into (for e.g. in grid computing) are aware of IAM products and technologies and what they should be doing to ensure their product will integrate well with existing IAM technology. This in case of authorization would automatically lead them to XACML.
One of things that really bothers me is the issue that people do not associate the authorization with a centralized management system and thus do not understand the need of standards for authorization resulting in being unaware of any standards. Besides that some of the architects approach the authorization as an extension of their business rules engine and thus miss the XACML aspect of the authorization. So, to some extend, the XACML is hurt by these mis(sing)conceptions of the architects in the enterprise.
Implementation Pattern in opensource - The opensource still seems to be trying to figure out the identity. Looking at the list put together by Jim Yang, we can see that opensource is still building the technologies as they need it. So, we are still looking for the Apache Server of Identity Access Management. Well incidently I did run into an initiative at Apache and was both overjoyed (that somebody is working on it) and was disheartened (I think they are on slightly wrong track [My thoughts]) after reading through the available documentation. Besides that I am of the opinion (after looking at other available stuff) that J2EE got the authorization API model wrong. This realization comes from the basic issue of how can you build a API model that is dependent a specific authorization model (in this case RBAC) when we already have had atleast three access control models (like MDAC, MAC, RBAC) that have come and gone. The basic question is "Can the user perform specific action on a resource" and not "Does the user belong to specific role". So, this is where I think we need a authorization provider (no role mapper is necessary for application!!) API which is built on XACML request/response model. Based on this understanding I would really love if opensource is able to figure it out the right way and would be more than happy to help them in what ever way I can.
end-to-end Identity tracking - James also raises the idea of identity enabled connection pooling. I think this points to the basic issue of end-to-end user transaction auditing, monitoring and access control. The front-end and business logic layers are mostly Identity aware (due to Web SSO) but we are completely at loss in transferring the identity to database system and other backend systems. In that regard, James approach would be a good start. But I am really looking for a complete data access control layer at this control transfer point or a standard way to transfer the identity to backend system so that they can do access control based on the identity (besides the "Run As" Identity that is used in most database application). I would really be looking forward to Access control product from Oracle and hope that it will have the ability to transfer the session identity from container to database as part of database call for authorization function or may be one of Application Server company (BEA seems to be well placed to do this with their weblogic and WLES) will release something to take care of this efficiently (i.e. with very low overhead).

So be it.