Identity and Access Management

Reclaiming your account: Password Reset/Forgot Password

2009-09-15T05:32:00.001-04: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-10T23:53:00.001-04: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-17T07:35:00.001-05: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-02T07:56:00.000-04: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-05T20:08:00.001-04: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-29T22:09:00.001-04: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-14T07:27:00.001-04: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-02T15:15:00.001-04: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-11T07:58:00.001-04: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-25T22:40:00.001-04: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-12T05:43:00.000-05: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-23T12:48:00.000-05: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-26T23:24:00.000-04: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-19T07:52:00.000-04:00

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-30T09:15:00.000-04: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-18T16:35:00.000-04: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-15T21:12:00.000-04: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-13T01:00:00.000-04: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-03T11:27:00.000-05: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-15T19:55:00.000-05: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-04T14:16:00.000-05: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-04T12:29:00.000-05: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-02T20:38:00.000-05: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-02T16:47:00.000-05: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.

The phase out of retail PC

2006-01-02T11:16:00.000-05:00

This idea started growing in my head after two events, one my parents started using their new PC and, second, CISCO bought scientific atlanta. Well seeing my parents struggle with the basic internet and window skills really made me understand that the PCs are an overkill for 60-70% of the PC users that looking to do basic things like check email, browse and listen to music and play media clips once in a while and a much smaller and simpler product should do the job.
Based on the way things are moving it seems like that is already at works. The industry thinks that the triple play will not stop at the last mile but will actually continue to the antenna terminal on the TV. And I think that this is where the retail computing markets will be making their move in near future. So instead of the triple play being addressed by separate components like digital convertor, cable modem, VOIP box, wireless router and a PC, there would be one single product to get the job done. In this way, these components will probably go through the same convergence process as has been the case in other areas of technologies (like wireless).
I understand that this idea has not been new and some (including me) have thought it to be the basis of Internet Operating System. But the important point is how will the various players fair in this. Now we can easily identify some of the good contenders like PVR/DVR/Set-top box, Retail Networking(modem, routers, voip hardware), PC retailers and some not so obvious [Crigley on Google-mart]. Each of the groups have their own strength and weaknesses and I guess only time will tell how they will fair. But as of now, I think PVR/DVR and Network will be fighting it out and PC business would become more focused on the enterprise, specialized retail and accessory business. The cisco's move to buy Scientific Atlanta in this regard and IBM move to get out of PC business, may be part of that or may be reading too much into them.
The cisco's move after integrating the aquired technology with their networking products makes them a great end-to-end networking technology provider for the phone and cable companies which at the moment no other company seems to be doing in the routing business (which I guess would be juniper, Nortel, etc). In addition to that their upward movement in the TCP/IP stack gives them the ability to push the intelligence in to network and help build the efficiency and controls that the phone and cable company may want.
In addition to the whole idea of software as service is very condusive for these new products. These products can subsidize their set-top boxes with the money from the payment for additional software services. This model gives the companies like TiVO a big advantage since they have existing product, presence and technology which can be a good starting point. But they still need to build support for additional products like VoIP and browsing capabilities to become a good alternatives. I guess we will have to wait and see who is able develop and execute a good business plan to achieve the end goal. The convergence by its very nature means that it will become very crowded very quickly and then the market will play its part in finding the companies that will survive in long run.
Before I conclude, I will try to put together a list of feature of various components and features of the package.

Set-top box
- Low cost box similar to networking and PVR products
- Large set of interfaces like bluetooth, RFID reader(??), USB (drives for storing personal information), Firewire, Wireless and other properitory interfaces to connect other products to the triple play medium (cable wire, phone wire, optic fiber).
- Scripting and development Engine - AJAX like application to increase responsiveness and allow developers to develop easy applications.
- Better (and I really mean better) input devices for User interactions.
Software as service
- Low cost rental model
- Searching/Information/Advertizement-on-demand service
- Multi-media management software
- Storage service
- Email service
- On-demand softwares ranging from basic office applications to photo-shop, etc available on per-use basis.
Better Mobile Platform - The convergence of Wireless mediums/protocols would ensure that new mobile computing products will be available which will use the same software-as-service model to deliver the software services with voice/handwriting recognition and/or better user input tools.

The toe nails of Identity Elephant

2005-12-20T13:19:00.000-05:00

I have over time learned that defining things has not been my strength and over time I have understood that most of us in Identity and Access space can run most of our professional life without have a industry standard definitions. But at the same time, I like to keep a glossary list handy which I attach to every project document and let it change as the client tries to make sense out of their environment.
After reading the Dave Kearns and Scott Lemon's thoughts, I was again reminded of the Identity elephants that seems to be in the room and how people are trying to find it. In that context I think I found that these two people are so close in their definition the way I understood them that I had to write about it. The idea in case of Scott is that Identity is "same as" while for Dave is "Identifying" (which for him somehow always leads to DNA, twins, etc, anyway this may be something for other blog). Now incase of an identification system, the identification means it needs to have information about the entity that it wants to "Identify". So, the process of "identification" for the system means that the representation of the "identity" in the system's memory is "same as" representation of the entity that system has received from the entity (through the authentication information/identifiable attributes). With regards to the other part of Scott's article that is about existance of "Observer", that ties in well with Dave's idea of "identify" that in order to get the "identifiable attribute" in the memory of the system, some one has to "observe" the entity and register its identifiable attributes and so this is an action that takes place before the identifiable attribute can be stored in memory.
So to summarize

Observer "observes" the identifiable attribute
Observer stores the identifiable attribute in Identification system's memory
Entity exposes its identifiable attribute(s) to Identification system
Identification System uses the identifiable attribute(s) stored in memory to check whether the Entity's identifiable attribute(s) is "same as" that stored in memory.

And thus we have identified the toe nails of identity elephant.

Authentisoft Introduces IDX EAP

2005-12-18T22:55:00.000-05:00

I am completely confused by this company's approach in the IAM space. I do not understand what their target market is and can only speculate that it will include small size business or may be a complete Java shop whose developer think this is a good "IAM" product. Take a look at the article (and the discussion ) that have come from Justen Stepka who works with the company. The product seems to be too little too late at first glance (atleast in IAM space) but then may be I donot understand the product and its complete feature set.

Internet Rebels

2005-12-18T12:01:00.000-05:00

After watching the Google EPIC, I had a burst of "creative" thought (which is very rare let me tell you) about a futuristic novel based in 2015 about a renegade who is part of a network of people who run a parallel internet over P2P protocol. The idea being that once you develop protocols to index and search the P2P member site using distributed indexes you may be able to browse the net anonymously. But after reading these articles, it seems to me that something like above may become a reality rather than remaining a fiction in my head. But seriously guys is it good to reject a more structured way to generate internet content just because the format is being proposed by companies that are trying to make money out of people's content. May be I am being too naive.

Federation revisited

2005-12-18T10:56:00.000-05:00

While going through some articles on the reports from Burton group on Identity Management, I ran into this article from Andre Durand. The basic point of contention was that Burton has predicted that Federation will not be separate product long term while the Patrick Harding contests that it will be a separate product. This point of view from PingID can be attributed to the fact that their flagship product is a federation server though they do provide other components like Token Service. But lets not go there and look at the argument. The basic point of the contention seems to be that the infrastructure needs a federation server to consume SAML assertion and generate internal SAML assertion that can be consumed by the internal infrastructure. But I am not sure whether that means that you have to setup a federation server the way described by them using this diagram. I see the work they describe more the job of a Token Service as I have opined earlier. (which I think is one of the good ways of implementing an Authenticaion web services) which will be used by infrastructure components to do the validation. I do not see the federation server becoming the point of entry in the infrastructure since there are much better products to do that job (like XML firewalls for web services and Web SSO products for the other browser based applications).
May be this is just the difference of level of technicality that we are at and Patrick Harding is trying to say the same thing as above and I am getting into the details.
Please also note that in case of browser based application most of the implementations that are taking place in this field are moving along the idea of Federation Server being the initial point of contact for SAML validation, setting up the session with existing Sign On products and then redirecting the browser to web application protected by the SSO product. Thus, the model provided by PingID makes sense for the initial part of the SAML validation but I am not sure when the third party applications will start shipping out with support for federation SSO (more specifically the Web SSOs and XML firewalls, some of which already support it) just like they have started supporting the concept of Single Sign On.

FSSO - where are we?

2005-12-10T23:44:00.000-05:00

With so many federated sign on specification out there, it was becoming really tough to keep track of them. The way I see, we can divide them in to community site initiated Identity URL based specs like SXIP (new addition), LID, OpenID, i-names(XRI) vs standard/large vendor initiated identity token based specs like SAML, WS-Federation and infocard.
Given that the community initiated specs based on URL based Identity have come together under YADIS (except SXIP and I am hoping they will join the party soon), where does that leave us with WS-*, SAML, Microsoft Infocard and Passel (with counter-signed and self-signed attributes). While the community based FSSO specs are consolidating, the businesses are rolling out services mostly using SAML to perform FSSO between the services that they are providing. We are still waiting for the Infocard and WS-Federation to pick steam. It seems that the infocard may be obsolete by the time it comes out if YADIS is accepted by the community (unless they find a way to coexist which I do not see at the moment given the love of SOAP on Infocard side and love of REST in the URL based identity) and SAML becomes the norm in the Business business community.
At this point one thing that is bothering me is complete lack of initiative from Yahoo, Google (more important) and ebay on the FSSO front. If these company "don't get it", the community based initiative may not succeed (unless somebody figures a way to integrate with them without their involvement). But the basic question is why should these companies "get it" i.e. what are they going to get out of this? Only benifits that I see for these portal companies is the ability to sign on more partners who would like to receive some sort of users' identity for better marketing purpose. So, the idea would be that as soon as you click on an advertisement, search item or any link to the partner site, the basic identity from these portal would flow to the partner site giving them the ability to customize the website based on the attributes like age, location, name, gender, etc. Obviously, this will extensively utilize anonymization techniques (like that part of SAML 2.0) to ensure that user information is not given out without his knowlege. At this point the game is getting very dynamic. A single new annoucement may change the way FSSO would grow over next few years which makes the whole game all the more interesting....

What is identity - In words of Bulla Shah

2005-12-03T11:49:00.000-05:00

I really like the way this this poem explores the basic question of "who am i" i.e. "what is identity". This poem was composed by Bulla Shah , a 17th century sufi poet, and used in a great song.
Bulla, who knows who I am?

Neither I am a believer (who stays) in a mosque
Nor do I indulge in actions of disbelief
Nor am I the pure one amongst the impure

Neither I exist in books of Vedh
Nor do I stay drunk
Nor do I remain stoned, rotting

Neither I am happy nor sad
Nor am I in the (argument of) Purity and Impurity
Neither I am (made) of water nor of earth

Nor am I fire nor air

Neither I am Arabic nor Lahori
Nor am I (resident of) the Indian City Nagaori
Nor Hindu nor Turk Peshaweri

Neither I found the secret of religion
Nor did understand Adam and Eve
Nor did I create a name for myself

From beginning to end, I tried to understand myself
I did not come to know of anyone else
I am not just another wise one

Bulla Shah, who is this standing?
Bulla, who knows who I am?

Neither I am Moses nor Pharoah
Neither I am awake nor asleep
Neither I am fire nor Air
Nor do I live among fools
Neither I am sitting nor am I in a tornado

Bulla Shah, who is this standing?

Anti-suite Approach

2005-12-01T07:04:00.000-05:00

This article talks about suite vs Anti-suite. Each of these approach have their own pros and cons and fit specific markets. Some factors that may determine it are
SMB (suite) vs Enterprise
Work with bleeding edge products vs conservative adoption
So, I do not think it would be appropriate to categorize any market whether it is network security or identity management as suite or anti-suite.

PingSTS Announced - Identity for Web Services

2005-12-01T06:55:00.000-05:00

Given that the InfoCard is based on this service, need to setup a working environment to test this integration. Besides that I am bothered by lack of tokens types on the output side. Anyway, will write about it more once I get chance to do the testing.

Looking back to look forward: Thoughts on HP acquiring of Trustgenix

2005-11-30T23:14:00.000-05:00

First Phase Provisioning

Access360
Business Layers
Waveset
BMC

Web Access Control

Oblix
Netegrity
Securant
DASCOM
Entegrity

Password Management

Courion
M-Tech

Meta-directory/Virtual Directory

iPlanet
Novell
Siemens
Zoomit
OctectString
RadiantLogic

Second Phase web services, federation, SOA

Trustgenix
PingIdentity
Sxip
SOA Software
Layer 7
Symlabs

Third Phase activity in applications, information governance, identity in the network, and role / privilege analysis

Eurikify
Bridgestream
Prodigen
TIzor
Consul
Virsa

Would be adding to the list when i get chance..

GRID: Globus Toolkit 4.0 - Authorization Model

2005-11-23T11:08:00.000-05:00

The feature list is

Support for PDP Chaining
Policy Combination algorithm Supported: DENY overrides ALLOW (permit overrides can be simulated by having a MasterPDP which will then controll the other PIP &PDP - Will need to specify sequence of the PDP & PIP Separately)
Supports the concept of PIP which works as Interceptor (like PDP) but does not return decision. It instead returns data which can be used by PDP (More info needed on how)
ID that will be authorized is extracted from the credential used by client to contact the service.
A concept of Resource Owner is supported which can be extracted from "resource, service or container depending on availability in that order of precedence"
Authorization Schemes supported
- self - Caller ID = Owner
- gridmap - Caller ID part of pre-defined list. This sheme also supports user ID mapping to local user id (how does that help or can be leveraged??)
- Identity - Caller ID = Specified ID
- Host - Called's Host ID = specified Host ID. Host ID being a special form of certificate with a common name (CN) corresponding to a name obtained from DNS or some configured service name. (How does this get mapped to caller, is the caller id = host id or is host id like a computer certificate in the Windows system??)
- SAML Call-out - PDP contacts a SAML Authz Service using request/response interface
- userName - Caller ID = JAAS authenticated User (who is authenticating and how is that being passed to PDP?)
The development involves the following - Please note all the plugins have initialize and close function
1. Implement the PDP interface - org.globus.wsrf.security.authorization.PDP :: boolean isPermitted(javax.security.auth.Subject,javax.xml.rpc.handler.MessageContext, javax.xml.namespace.QName operation). This interface also hase capability to get policynames and get/set policy (org.w3c.dom.Node)
2. Reference the PDP from a security descriptor - Change $GLOBUS_LOCATION/etc/<service name>/security-config | <service name>-security-descriptor.xml add the <authz value="ascope:class name"/> where ascope is scope which is an authorization scheme "context" used to distinguish different authorization schemes with the same implementing class within the chain.
3. Test the PDP - run client
4. Implement the PIP interface - org.globus.wsrf.security.authorization.PIP :: collectAttributes(Subject subject,MessageContext ctx,QName operation)
5. Reference the PIP from a security descriptor - <authz value="ascope:PIP_Class pdpscope:PDP_CLASS"/>
6. Test the PIP - the order of execution of PIPs and PDPs depends on the order in which they were specified in the authorization chain configuration
7. Communicate an attribute from PIP to PDP - e.g. - subject.getPublicCredentials().add(attribute); & subject.getPublicCredentials();
8. Add a configuration to an interceptor - Use the service deployment descriptor to pass the data to PDPConfig used in initialize call. The D.D. is located in $GLOBUS_LOCATION/etc/<your_service> and <parameter name="ascope-attribute" value="notmanager"/> i.e. scope_name-attribute_name (Guess can not have hiphenated scope name??)
Next Steps -
- Develop Attribute/Role-based Authorization - Proper representation of attributes need to be developed which can be transferred accross the PDPs
- support for fine grained expression of "delegation of rights" =
- pluggable authorization engines
- lazy collection of attributes
- caching of decision/attributes
- and metadata about attributes/interceptors
Resources - GlobusTK 4.0 Release Manual, WS Authentication and Authorization documentation, GridShib (Globus Toolkit with Shibboleth), Community Authorization Service

Linkmania

2005-11-20T23:13:00.000-05:00

Links

Role Based Access Control
IDManagement Problems and IDentity Management Objectives
Globus Toolkit (Summary), DACS (to read) and Acegi (to read) for Access Control
Web 2.0 Components
Introduction to biometric device
Active Directory Unix Integration
IIW2005 Talks
GSA Federal Identity Management Handbook covers User Registeration and Issuance Guideline(identity proof, card issuance), Physical Card requirements, Smart card specification, Implementation planning guidelines.
Very basic introduction to PKI Enabled Email security
Web Services Protocol specifications List
VMWare 2005 World Presentation
Open-source Identity Management Tools
Identity Management project Basics
Comparing EPAL and XACML - bottom line XACML is a super set of EPAL.

Consentry LAN Controller

2005-11-20T22:54:00.000-05:00

Another company in the "identity enabled network" space besides Identity Engines that I talked about earlier
Moral of the story seems to be that

Trusted Identity store (like LDAP) needs to be integrated with network
Application access policy must include Identity & Roles
Application Control beyond port.

Nothing new here. Besides looking at the product itself nothing new on the authentication side (seems to be similar things that other network product would support). But at the same time there are wide variety of applications that are supported "out-of-box" though I am not sure what we are going to achieve by simple performing an allow or deny at the application level since that is as good as port level access! (nothing more finegrained). The field of identity enabled network seems to be the next step in the growth of the identity. It would be interesting to see what other companies are working on.

Global Identity Body

2005-11-11T09:19:00.000-05:00

I think we really need to see how the identity is managed in real world and may be that can help us figuring out how it may work in digital world. So we would need a passport like mechanism, which would assert very basic information about the person across the international boundary and that is where I think we may concentrate at these international conference (any thing beyond that would be equivalent to boiling the ocean). Then we would need trusted bodies for various context. For example the international transactions would need banks working as intermediatery (as used for trade by companies across international boundaries) and then you may have technical bodies like medical bodies who may vouch for their members in transactions. So, I agree with the basic idea that there would be large number of bodies and also think that there would be multiple protocols that would be developed for and by each of community as they need to share this information. I think the idea of having a single standard across the board is a dream.
We have to remember that the identity is not some thing like internet which was developed completely from scratch and hence the people who joined later accepted the work of the earlier groups. Neither is it like the desktop technologies which were accepted easily due to prevelance of single OS.
That's why we should not expect a single protocol or even "meta-identity" system to be accepted by the world because paradigms have changed or are changing in the digital world.

Identity/Reputation management with Opinity

2005-11-11T07:39:00.000-05:00

What is a product like this going to buy me as a citizen of web? I can see their idea of a central repository of user reputation (something similar to Credit Reporting company). But all the big sites have their own repository and why would they want to share that. So, their basic approach would be to get the smaller websites to get to use this service. Now that is a big issue because why would most of these websites want to purchase a service they do not need. As soon as the customer pays via credit card, these people do not care about the reputation of the customer. So unless this system can help them
Lets take the model from customer point of view. Most people would like to get tangible benifits out of this before they would be ready to aggregate their identity information in one place. This could be in form of discount in online stores. In addition to that the reputation needs to be integrated with a identity engine that can build a central repository of their profile (which will include their blogs, comments on other websites for products, etc) across the web which can then be converted into his reputation (because without the "identity" you will not know who are the people talking about since there could be really large number of "John Doe" out there).
May be I am thinking too far into the future. At the moment, it could be more like something that gamers and others involved in online activities (like chat ) would use to aggregate and share their information out of box.

Identity Map

2005-11-11T07:00:00.000-05:00

Good idea and summary of various type of information that is associated with the user i.e.

Names
Characteristics - Static and dynamic
Relationships - I am not sure whether Relationship should be separate from the role. I am assuming that any relationship with always have the roles automatically defined for all the participant of the relationship either implicitly or explicitly.
Roles - See the Relationship and that is why roles by them selves may not make sense. These have to be in a given context and the context being the relationship or community of which relationship is part of.
Locations
Experience - Experience would result in knowlege!! right? and so knowledge would be super set of experience and information that was gathered through experience of others (i.e. teaching, reading).
Knowledge -
Reputation

What do you say?

Identity Engines Delivers Platform for Network Ide?

2005-11-11T06:51:00.000-05:00

So finally the company is out with the product. I have been hearing about this company for some time now. Any way seems like these guys are catering to the requirement of companies that want to control access to their network in much secured fashion. Most of these guys have need to perform the following functions

Sequestering the machine hooked to the environment unless validated (so it may not even be able to get a IP via dhcp)
the laptop would be checked for latest version of firewall, antivirus with the latest updates.
The user would need to authenticate to ensure that it gets access to the network.
(Not seen a lot though) if the user tries to access an application this access needs to be managed.
Auditing all these events with additional information for monitoring and analysis.

W.r.t. the third access requirement, I have seen most of the company already have something installed. For example web applications would have the Web SSO products. But most of the client server applications (which are not being fixed since they are not broken) are still out of the perview of the centralized solution. Now looking at the solution it seems to provide the

sequesting of machine - this is a tough nut to crack but I think combining with user authentication at switch level can achieve the same result.
user authentication - which is provided by most of the managed switches through support of 802.1x and RADIUS (I will be implementing something in next few days for my company and will have more to write about it at that time)
Application access control - I am not clear what is the mechanism implemented with regards to mapping the identity to a machine after machine has been authenticated. If it uses the IP address or mac address, then theoretically the battle is lost since these can be spoofed. So, would really be looking forward to get information on this.
Security Compliance - I did not see feature support for making sure machine is compliant before allowing it on network.

Something else that is bothering me is the possible requirement of provisioning the switches for sequestering new machine. I am not sure how comfortable the network guys would be with an system managing their boxes "automatically". I know that a lot of firewall and IPS do perform such operations but still it may be an interesting issue.

Quick and dirty identity management

2005-11-10T22:32:00.000-05:00

That is what tells me that we really need to develop a open source identity management interface for people to be able to do the basic

User CRUD
Password management (password reset)
User data management
and basic user provisioning to other products

Oracle adds fine-grain features to ID security C…

2005-11-06T23:49:00.000-05:00

Seems like the fine grained authorization is really heating up!! But let's wait and see what is Oracle's idea of the finegrained access control.

Vendor Installation News

2005-11-05T00:52:00.000-05:00

I see a lot of releases on the vendor installations. This is an attempt to capture them on single page.

Mercer Human Resource Consulting - Trustgenix
International Bancshares Corporation - Secured Services Inc
Wendy's International Inc - M-Tech
GM, GE, T-Mobile - Sun Identity Manager
Toyota Financial Services, Principal Financial Group,Swedish Police - Thor technologies
SunTrust - Courion

ID-entity Blog Launch - Lessons from IIW2005 [Li…

2005-11-02T16:39:00.000-05:00

Seems like somebody else is also bothered by complete lack of discussion of Liberty/SAML in the Identity 2.0 world like me

The browser as the Virtual Directory GUI

2005-11-02T16:37:00.000-05:00

I think most of the people will agree that the basic issue with the auto-form filling is storage and security of that storage. That is what makes the existing auto-fills a big no-no for "informed" users. So, till we have browsers that are developed with very good built-in data security through smartcard or encrypted USB support we can not go too far with the whole idea of identity storage on the client.
The client till that time will continue to make a good pitstop that will allow the end-user to controll what is going from the IDP/Identity Provider to Service Provider.

Internet Infrastructure Ignorance

2005-11-02T14:28:00.000-05:00

There is an existing product that is built around the XRI. Besides that the basic issue of multi-identity and associated management w.r.t. End-user is something that the products and protocols have to manage.

Anonymous Identity

2005-11-01T08:49:00.000-05:00

This is one of the worst reason I have heard against the anonymizers. Now why do I have to make myself known to the whole world if I donot have faith that the website that I access do not have adequate resources or will to protect my identity as is apparent from the way the big companies have failed us.
So these services will always fulfill a requirement in the world.

Purisma Launches Revolutionary Solution for Custom…

2005-10-31T14:00:00.001-05:00

The basic concept seems to be similar to that developed by SRD that IBM purchased this year. This whole section of knowlege generation through correlation whether it is through desktop content or database content is something that would be interesting to watch. And the next step that would come in is who is allowed to see the information that is found this way.
So due to privacy issue it would be really tough to use these type of products across multiple channels of the companies. Before the companies really go ahead and start doing these corelations they will really need think a lot!

IdentityBridge Provides Protocol Translation to Li…

2005-10-31T13:12:00.000-05:00

I donot get the business model for this i.e. what is the customer base for this product? The way I have seen not many people have purchased federated SSO products and the one that have expect the vendor to provide implementation of the two competing protocol and all the associated version. Now after purchasing a federation product why would you want to buy a protocol translating product.
Need to really understand the why do I need it!!

Expedia Ensures Customer Security

2005-10-29T23:40:00.000-04:00

Hmmm... is this the beginning of the adoption of SAML as federation protocol by corporatate websites. It would really help everybody if it really kicked off... But I am not sure how well the identity systems of the enterprises are to be able to go to the next step of federation. Guess if the service providers build it, they will come!!

Yet Another Decentralized Identity Interoperability System

2005-10-29T18:22:00.001-04:00

Assumptions:

Open
Identity is in URL format (guess email is not enough?)
easy for developer

Profiles
Browser based Authentication:

The service provider contact the IDP URL to get the capability and based on the authentication protocol chosen start the authentication - Now a few things here. First of all this means that SP needs to understand all the authentication protocols i.e. be it LID, OpenID or something else. Does not make a lot of sense but fine, lets continue.
SP uses the "protocol supported way" to redirects user to IP which authenticates the user
Profile exchange: Well if you need to get specific data about the user you need to ask for the Identity URL like IDURL?xpath=field that is needed&lid=SP's Identity

Now only thing is why do we need to have this new "federation" protocol when we already have it in Liberty and SAML. I guess it is all about the removal of SOAP and making the protocol simple. Other than that why sitdown and redo work that people have already done? Won't it make more sense to sit with the others and get a single way to get the same thing. The Liberty has already done the work. It seems the protocol needs to be enhanced just to make the user part of the existing standards and give them control over their data during profile transfer and linking. So guess let's wait and watch.

IIW2005: Attention Data as Identity

2005-10-28T18:42:00.000-04:00

I love the idea that I can sell my web browser's bookmarks and history. How I wish I had not deleted my browser history.
But I guess Attention Date = Identity is too far-fetched. It could be more like a profile or persona but does that uniquely identifies me? Well guess that goes to what do you mean by identifies. If the identification is a "checksum" of my data then yes but other than that it resembles more like the way a corporation would like to see me i.e. a classification system.

Analytics and Web 2.0

2005-10-28T16:32:00.000-04:00

Based on what I have seen the Identity in Web 2.0 is about > It is owned by User instead of corporation > Since it is owned it has to be managed by user which brings up the issue of what if user donot manage it actively > it is distributed by user which means user has to look at all the fine prints on what a company that is going to accept its data will do with it. Well I am not sure how different it is compare to now!! > All the work that the identity does is owned by user. guess it is no different than now unless we can build services which can make this process more secure and thus give the law and user more faith on the identity systems. Then the next step comes in of allowing users to sell its attention/web history to the analytics??

Identity as a Service

2005-10-28T15:09:00.000-04:00

The identity as a service makes sense just like Credit card services. I have heard business plan around them almost a year back but did not hear anything after that. May be now is the time to search them out.

Identity in 2.0

2005-10-18T23:59:00.000-04:00

Some summary!!

Beyond Java

2005-10-18T23:52:00.000-04:00

So far the way I see it the language have come one after other i.e. machine code, assembly, 3gl structured languages and scripting language being the next stop. But this has not really caught on. To me this is due to the fact that most of the people see scripting language need to replace structured languages like Java, C, etc. May be better way to look at it is to see scripting languages built over structured language where the third party or OSS base components would expose hooks to write business logic using scripting language and business processes will be a configuration (like a workflow configuration) process rather than code development process. Even then I have not been able to solve how the frontend is going to integrate with this development model.

Case Study: Furthering Role-Based Access Enterpr…

2005-10-18T23:41:00.000-04:00

Two obeservations 1. Now case studies are mostly from University which seems to be due to company's not going on record with the products that they have implemented. 2. TNT has interesting technology and looks goods as a way to take the identity to a level where it would be easier, probably faster and cheaper if this is based on standard so that cisco routers would be able to use the information and route stuff without any compatibility issue. 3. Another thing that bothers me is the IP stack changing technology which may be found intrusive by most of the people a. It is coming from a host firewall guys and it is free while the appliance costs some money b. This technology can support multiple domains and configurations (like vpn technology) Good technology to follow till a big company buys it and integrates and tests it well making the client free (the acrobat/plugin model). .

Ringtone Purchasing Round 2

2005-10-17T09:53:00.000-04:00

I am not sure how can the third party deliver an application or service without information about the platform from which the ring tone request was sent (if that is not provided along with cell phone number but then I am just an Identity guy not a cell phone tech expert and do not know about the standard in this field). But I am bothered by cell phone company as “big brother” who own the medium, authentication technology, and the gateway to ecommerce over an unencrypted medium which makes them a very big owner of information on user physical identity, habit, social connections (guess phone usage given you a good idea). I am sure the silos within the company itself may be keeping this information distributed but as the integration of these identity silos are completed over time think of the information they have access to (if the ecommerce through cellphone takes off). So going back to your earlier article, this is probably the biggest difference between Apple iTunes and ring tone purchase model. In case of iTunes, the Apple is not in a good position to collect this kind of data and the transactions can not be correlated while in case of Cellphone the company can become quickly very powerful and start selling user’s habits and social contact info (without providing their personal information) to ring tone providers to allow them to better customize the ads etc on per-user basis. Is it good or bad will probably depend on what that information is used for!

Ringtone Purchases vs Legal Music Downloads

2005-10-14T13:42:00.000-04:00

The basic difference between the two approach is that of Federation. Interesting thing to look at with regards to how future federations would work. An important issue that it brings out is that I would really want to understand how that mobile charging works (in terms of privacy and transaction). Does this system makes the identity provider i.e. your cell phone the single point that can use and sell your buying habits to the highest bidder (or all the bidders).

Bank hits back at phishing with security trial

2005-10-14T11:15:00.000-04:00

Guess they never read this . But at the same time a start! Still the idea of transaction authentication is better than person authentication. A good food for thought w.r.t. my ideas around identity.

Jabber HTTP Authentication Protocol

2005-10-14T09:09:00.000-04:00

Living in the Browser world we tend to forget that there is a big issue around cross-client federation. More on this later.

Experts give identity management advice

2005-10-11T15:52:00.000-04:00

Points raised

Process and System Integration are challenges
"Identity Management is viewed to be responsibility of employees in charge of physical security" This is totally against all my experience in financial industry where the identity management is typically part of the Risk Management group and that co-ordinates with physical and HR to develop and implement identity management solutions. But at the same time HR is the golden data source in most of the place.
"One ID across the organization" mostly a dream every body wants but nobody has (but there are instances where organization have been able to achieve it atleast for employees though not for customers.
"Biometric is the key to solve duplication" but biometric can not be converted into identifier. It is used as authentication data but not as identifier.

SSO Solution

2005-08-11T12:03:00.000-04:00

I saw this query on one of user groups

We are looking to move to a SSO solution, but were wondering what everyone else is doing? we have 5K + employees that all need access to various platforms (Sun Solaris, VMS, AIX, SCO, HP-UX, Windows, Citrix, AD, Web, etc).

Is there some sort of app or some such thing that will do a cross-reference of userid's? Or do we even need to worry about that (the 8-character limitation on the Unix boxes)if we implement LDAP or AD?

and I thought that this reply should give a starting point to the complete domain of Identity Management for solving the issue.

Well my suggestion would be that you should consider the various approaches available to you and probably should implement something that suits your requirements. The various approaches available to you are

Consolidation of Authentication repositories well this refers to the basic idea of setting up an enterprise directory which all the products can tie into for authentication purpose and to some extend authorization too. This would essentially mean that there is one id and password that has to be typed by people to login to all the integrated applications (which has its own pros and cons in terms of ease of usage vs security of systems)
Consolidation of Authentication entry-point - Most of the web applications can be consolidated to use web single sign-on system which can be tied to directory server if needed. This would allow the applications that do not provide interface to integrate with LDAP for authentication to be tied together by off-loading the authentication and authorization to a single entry point (the SSO solution). This would also help build the starting point for federated sign-on infrastructure.
Consolidation of Administration This is where the Identity Management solutions like SIM (look below for other possible products) can be set up to integrate with rest of the infrastructural components that can not be consolidated (for what ever reasons) to be provisioned through a single provisioning and administration system. Please note that implementation of Identity Management solution is a very complex undertaking and is very expensive in terms of licensing and in-house training and is not for faint hearted. In addition to that it comes with a lot of features (that may not even work properly or suit your needs) like approval workflow (to approve creation of new accounts), provisioning workflow, rules, password and account data synchronization and compliance management.
Consolidation of Synchronization A lighter version of the Identity management product is the Meta-directory and Password synchronization products which can be used to synchronize the account (and password) information across multiple environments without the overhead of workflows, etc.
Reduced Sign-On A set of products that run on client desktop and track the system that client is trying to access and automatically supply the password.

FIM and IP Based Authorization

2005-07-11T02:08:00.000-04:00

In the world before the FIM, a lot of technologies were used to implement the federated single sign on. A very common way to allow corporate level access to services, was to allow all the users coming from a specific range of IP (usually the corporate proxy server of client) full access to the service without requiring authentication (though the identification may be implemented for personalization purpose). But with the development of FIM standards, does it make sense to continue to require the IP based authorization in addition to the FIM Sign On or does it give just an additional level of "security" at the cost of sacrificing convinience (people can only access the service from corporate network and not from outside unless VPNed to office)?

Biometrics: Some thoughts!!

2005-07-06T00:50:00.000-04:00

After a quick read of thoughts on problems with biometrics , I was thinking how the accounts can be accessed after a person/owner has died. For example if a system is built that provides access solely on biometric authentication (without any escrow system in place), what would be the process to access those accounts after the owner has died. Does this mean that a biometric based security system can not be built without an escrow system in place.
Also, does it make sense from a liability point of view to become owner of biometric data. Just in case more stringent privacy laws come in to force and/or a precedence is set specifing the data owner can ask the data manager (enterprise that has the information about the owner) to pay for the damages caused by the loss of data, the biometric database would become a huge liability for any enterprise.
Thoughts??

Credential Mapping/Management, WS-Trust: Some use cases

2005-07-05T00:42:00.000-04:00

The basic idea of Credential Mapping service is to provide necessary data to the service's client which will help client to identify with a specific security domain. Based on the security policy requirements of security domain, this authentication and identification data can take various forms like id/password, token (cert, kerberos ticket, etc.). This concept has been implemented in kerberos Ticket based authentication system, Global sign on (GSO), Credential Mapping Providers, Security Token Service and enterprise reduced sign on. In this article I will try to discuss why such a service is important as a separate independent service within an enterprise or for an end-user.
As discussed above, the credential mapping or token generation service (here after referred as security token service or STS), has been an important part of Authentication systems, Single Sign on integration, Legacy Application integration, and Federated Sign On. Due to the wide variety of the application that can actually use such a service, it would make sense to develop an infrastructure that provides solely this service. The other infrastructural components can integrate with STS using various interfaces (like WS-Trust, Kerberos TG Service, and so on). I will try to explain some additional use-cases / reasons why this service is important as a enterprise level service instead of being part of individual solution.

Federated Sign On: I assume that based on the IBM and PingID design descriptions, there is an understanding in the FSSO space that the STS is one of the ways to go. At the same time I have been thinking that STS is an important component that if separated, can help build a more secure federation system. The federation single sign on is key to other enterprises and services and thus comes with a very important responsibility of protecting it. So apart from the standard ways to protect, one of the idea that would make sense would be to ensure that the Federated SSO infrastructure can be broken in to separate components and managed separately to reduce the chance of external and internal misuse. In that case, the STS would be a good representative component that can be managed separately from the rest of the Federated SSO infrastructure.
Desktop Single Sign On: Well with the idea of user-centric sign on/identity management (aka. infocards) taking hold along with good deal of enterprise reduced sign on products already in place, the concept of desktop based single sign on solutions is well entrenched in the market. While the infocards is basically built on the idea of the WS-Trust from the bottom up and thus would require a STS service, the enterprise reduced sign on have not yet looked at this aspect of the market (or atleast I do not know of any such product). At the moment most enterprise reduced sign on products are built around the basic idea of password based sign on with a back end credential manager that manage the identity's password. These product in combination with password synchronization tools are giving a good ROI as identity management solution. This segment of IAM has been missing from the Federation Sign on discussions (like Liberty and SAML) and is very apparent in the profile descriptions which do not consider desktop based Identity provider as a possibility (though interpretation of such a solution is possible). I think as these two parts of IAM solution set need to come together. We should see the move of Enterprise Reduced sign on(Enterprise RSO) products to accept the concept of STS and the Federated SSO standards to acknowledge / define the desktop based signon profiles much better. This would mean that if Enterprise RSO need to grow it must try to break its solution in to desktop based application recognition technologies and token/password retrieval functionality with later being part of Enterprise/Personal STS infrastructure.
Personal Identity Providers: The idea of personal identity providers have not been a something that I have seen discussions about. This basically is built on the requirement that 80-90% of the web sites that persons access do not need personal information for security purpose but to provide more personalized service. In order to provide "persona" information to these websites, external Identity provider is an overkill. It would be worthwhile to develop a personal STS system (some thing similar to self signed certificates) that would be fully controlled by the user and will not depend on existance of public identity providers. I feel this is one of the basic reasons why the PKI never took off since there was no desire of the industry to provide an out of box experience to the users which would hep them get acclimatized to self signed certificate system and then gradually move to public certificate providers for premium services. This means that the STS system has to be built into every user terminal and tied to the user's session on that workstation. Another important facility provided by these personal identity provider systems is to have usable STS system even during Identity Providers downtime (due to either attack or being non-reachable due to network not being available or some usecases around providing identity to network centric identity systems) being a secured cache of claims. An important point to keep in mind is that personal identity provider should not be built in to a user centric solution like infocard because that makes them an easy target for the hackers. This service has to be externalized and standardized so that various implementation can compete with each other based on the user's desire of security and personalization (so for example there can be smart card based solution along side software based solutions).

One of the basic premise of this idea of separate STS is the deployment of a service that will become single point of attack for getting passwords and/or tokens. But I think, based on the acceptability of the single sign on technologies and proliferation of password databases, password synchronization technology, the STS service is very much acceptable as an Application/Database layer implementation (instead of living in DMZ) with in an enterprise.

Vendor List

2005-05-31T23:01:00.000-04:00

Updated: November 12 2006

I am trying to come up with the list of vendors and associated products in the Identity and Access Management arena. Please note that this list is based on marketing/public information and my understanding of the terms which may not comply with any specific groups' definitions and/or requirements. This is by no means a complete list and will keep growing as I get more time to add them and find more companies (any help on that front will be really appreciated). Before we go further along, lets try to define what each of these product typically do so that my mode of classification may make sense or any flaw in my classfication will become apparant.

Identity Management/User Provisioning These products typically provide the facility of Workflow-based Identity provisioning, password reset, identity reconciliation/discovery, delegated identity administration and self-service features on wide variety of identity platforms (like LDAP, Unix, Windows, Mainframe, ERP, CRM and so on). In addition to that most of the product also provide ability to implement rule based compliance validation.
Single Sign On Typically these product allow users to authenticate in various ways (i.e. RADIUS, SPNEGO, form based, certificate, etc.) and then provide access to web application without request for another credential. In addition to that these product also provide basic access management/control over resources (web incase WebSSO).
Access Control and Enterprise Rights Management there are new breed of independent product that provide fine-grained access control. There seems to be some confusion in market on what constitutes access control. Most of the customers that I talk with understand the access control as a Policy Evaluation system that can be invoked by application to check whether a user has access to the data. But at the same time, some other vendors (which probably come from Data Encryption world) see access control more as Role/Rule based data decryption process. This to me sounds more like Enterprise Rights Management which is just a special case of access control where the enforcement approach is built into the system.
Reduced Sign On/Enterprise Sign On These are typically windows desktop agent based product that automatically fills user's ID and password in to an application (web, windows application or mainframe/terminal application) once accessed via desktop.
Federated Identity Management/SignOn Refers to products that provide full implementation of SAML 1.0, 1.1, Liberty Alliance and WS-Federation protocol/profile implementations. In addition to that some product also provide cross-domain Identity provisioning.
Strong Authentication Refers to products that provide authentication approaches better than password. This typically includes products like token, biometric and new approaches to strong authentication and anti-phishing solutions.
New Stuff Refers to new breed of products like identity appliances which are out there.
Network Access control Refers to products that allow control of network access based on user identity and optionally additional criteria like virus definition, application protocols, etc

Please feel free to provide your comments on the basic classification definition, product mis-classification, personal product preference or any thing relevant to this discussion.

Vendor	User Provisioning	Single Sign On/Access Control	Federated Identity Management/Sign On	Directory	Others (Privacy, Compliance, Strong Authentication)
A10	IDSentrie 1000 Identity Appliance (UNIFIED IDENTITY MANAGER)	IDSentrie 1000 Identity Appliance			IDSentrie 1000 Identity Appliance (Network Event Manager and Correlation)
ActivIdentity/ActivCard/Protocom		ActivIdentity SecureLogin Single Sign-On (Reduced Sign On) ActivIdentity 4TRESS® Authentication Server (Centralized authentication Service- Does this support Web SSO??) ActivIdentity AAA Server (Network Authentication Server for RADIUS,TACACS+, and 802.1X)			Smart card, USB Token, One Time Password, fingerprint (Strong Authentication)
Aladdin	Enterprise Single Sign-On (SSO) with eToken (Reduced Sign On)				USB Token, OTP Token, Smart Card (Strong Authentication)
Apere (Product Data protected)		IMAG - Identity Managed Access Gateway (IDentity Appliance??, NAC??)			USB Token, OTP Token, Smart Card (Strong Authentication)
Applied Identity		Identiforce (NAC, Identity Appliance)
Arcot					ArcotID (Software based PKI which protects the private key by Camouflage it)
ASG	ASG-Entact ID™ for Enterprise Identity Management	ASG-Focal Point™ for Enterprise Single Sign-On (Reduced Sign On)		ASG-RadiantOne™ for Enterprise Identity Integration (Virtual Directory)
Authentify					Voice/Telephone Based registeration(Strong authentication using telephone)
Avatier	Identity Management Service (Password reset, password policy enforcement, (de)provisioning, request)
Aveksa					Aveksa (Compliance Automation)
Axalto					Smart Cards(Strong authentication)
Bayshore Networks		SingleKey (Appliance, Reverse Proxy based SSO, fine-grained Authorization-Not sure)
BEA		AquaLogic Enterprise Security (Fine grained policy evaluation)
Beta Systems	SAM Jupiter (Workflow, Rules, Provisioning, Role Mining, password management, compliance, reconciliation )	SAM enterprise Single Sign-On (Reduced Sign On)
BHOLD	BHOLD Modeler, BHOLD Auditor, BHOLD User, Authentication, Authorization, Provisioning Manager and SSO Portal (Role Management)
BMC	CONTROL-SA/
BNX					Unable to locate the company website bnx.com but it is in strong authentication.
Bridgestream	Bridgestream (Role Membership and Role hierarchy management)
Caymas		Identity Driven Access Gateway(NAC)
Centrify	DirectControl Suite (AD based Identity Management)
Computer Associates	ETrust Identity Manager (Provisioning, Self-service, workflow, password management)	eTrust Access Control (Operating System Single Signon and Access Control ) eTrust SiteMinder (Web Single Sign On and Access Control) eTrust Single Sign-On (Reduced Sign On) eTrust TransactionMinder (Web Service Signon and Access Control) eTrust Identity and Access Management Toolkit (Fine grained Access Control)	eTrust® SiteMinder® Federation Security Services, eTrust TransactionMinder	eTrust Directory	eTrust CA-Top Secret Security (Mainframe Security Administration)
Cisco		Cisco Clean Access/NAC Appliance(NAC)
Citrix		Citrix Password Manager (Reduced Sign On)
ConSentry Networks		NAC(NAC)
Courion	AccountCourier®(Provisioning), PasswordCourier(Password synchronization and reset), ProfileCourier®(Self service), Role Management (Role membership and hierarchy management)				CertificateCourier, Compliance Courier
Credentica (No known product)
Digital Persona					DigitalPersona Pro (Strong Authentication - Fingerprint)
diamelle (Advertized as opensource. Can not find the location for the source)	Identity Management	Authentication Server
e-Meta		Right Access (DRM/Enterprise Rights Management?)
Encentuate		Encentuate TCI(Reduced Sign On with multiple authentication factor)
EngiWeb Security (Italy)	Profile Manager (Role Design and Management), Provisioning Module (Provisioning)	Web Single Sign On (Web SSO)
Entegrity		Entegrity Assure Access(DCE based Single Sign On)
Entrust	Sun Identity Manager	Entrust GetAccess™ (Web SSO and access control), Passlogix v-GO Single Sign-On (Reduced Sign On)			Entrust USB Tokens, Entrust IdentityGuard™ (Strong Authentication)
EPOK Inc.		EPOK ISE System (Enterprise Right's Management and Access Control)
Eurekify	Sage Discovery (Role Discovery) Sage Audit (Role Reconciliation) Sage Compliance (Role Compliance)
Evidian (Enatel)	Identity Manager Provisioning Manager Approval Workflow	Secure Access Manager-Standard Edition (Legacy and Web Environment) Secure Access Manager-Web Edition Evidian Secure Access Manager-J2EE SSO Xpress-Standard Edition (Reduced Sign On)
Fischer International	Identity Management (Provisioning, Compliance, Password Management, Self-service)
ForeScout		CounterACT (NAC)
GemPlus					Smart Cards, OTP (Strong Authentication)
HID (Indala)					Smart Cards (Strong Authentication)
HP	Select Identity	Select Access	Select Federation		Select Audit
IBM	IBM Tivoli Identity Manager	IBM Tivoli Access Manager for e-business (Web Single Signon and Access Control) IBM Tivoli Access Manager for Operating Systems (Operating System Single Signon and Access Control) IBM Tivoli Access Manager for Business Integration (MQSeries Single Signon and Access Control)	IBM Tivoli Federated Identity Manager	IBM Tivoli Directory Server IBM Tivoli Directory Integrator(Meta-Directory)	IBM Tivoli Privacy Manager for e-business, IBM Tivoli Security Compliance Manager, IBM Tivoli Identity Manager (Built-in compliance), XML Security
IdentiPHI		IdentiPHI™ Enterprise Security Suite (Reduced Sign On), IdentiPHI™ EPM (Network Access Control)			CompliSoft(Compliance)
Identity Engines	Ignition 3000E (Identity Appliance for Provisioning to switches??, RADIUS Sign On)	Ignition 3000E (Network Access Control)
Imanami	SmartDL (Group Management), WebDir (Self-service tool for directory)				Directory Synchronization
Imprivata		OneSign Platform (Reduced Signon)
i-Sprint		AccessMatrix USO (Reduced Signon), AccessMatrix™ Universal Authentication Server (Centralized Authentication Server, Token Management)
Jericho Systems		Enterspace Security Suite (Fine-grained policy evaluation based access control)
Juniper Networks		Unified Access Control(NAC)
M-Tech	ID-Synch (Provisioning), P-Synch(Password Synchronization, Reset), ID Certify (Account re-certification), ID-Access(Self-service Access Control), ID-Discover, ID-Telephony (Voice/Telephone based Password reset)
MaXware	Identity Center (Provisioning, workflow, password management, audit and monitoring), MaXware Data Synchronization Engine (Data Syncrhonization), MaXware ExpresSync(Lightweight Data Sync??)			MaXware Virtual Directory
Microsoft	Microsoft® Identity Integration Server 2003 Enterprise Edition (Synchronize Identity, user account provision, password management)	Microsoft® Internet Security and Acceleration Server 2000 Enterprise Edition (Limited Single Signon and Access Control) Internet Information Services (Single Sign On via SPNEGO)	Active Directory Federation Services (Federated SSO for Web Browser and Web Services - Part of Windows Server 2003 R2)	Windows Server 2003 Active Directory,	Strong Authentication for Microsoft Web Application and Microsoft Clients, Certificate Lifecycle Manager (from Alacris)
NetPro	SecurityManager
nCipher(Abridean)	Provisor (Group Manager, Compliance Manager, Password Manager, User Manager), keyAuthority (PKI Management)				Secure APP for Peoplesoft (Access Control by Data encryption and policy enforcement), KeepSecure: SecureDB for column level database security (Access Control by Data encryption and policy enforcement), KeepSecure: SecureFS for File security (Access Control by Data encryption and policy enforcement) - More Information on supported policy model needed before classifing as access control product.
Novell	Nsure Identity Manager (formerly DirXML) (Previously a Meta-directory product but Enhanced Provisioning Module provides approval workflow, delegated admin)	iChain® (Web Single Signon and Access Control) Novell Nsure SecureLogin (Reduced Sign On)	SAML Extension for Novell iChain, Liberty identity provider for Novell eDirectory (Liberty 1.1)	eDirectory®
OMNIKEY					Smart Card (Smart Card & Object)
Oracle	Oracle Identity Manager (Provisioning - Previously Thor Xellerate)	Oracle COREid Access and Identity (WebSSO), Oracle Enterprise Single Sign-On Suite (Reduced Signon From Passlogix)	Oracle COREid Federation	Oracle Internet Directory, Oracle Virtual Directory
PassGo Technologies	Syncom, Resync, InSync (Password Synchronization and Management)	SSO Plus (Reduced Sign On), Webthority (Web SSO?), SSO (Not sure?)			Defender Tokens(Strong Authentication), Software Tokens
Passlogix		V-Go SSO (Reduced Signon)
Persistent Systems				enQuire Identity Server, enSure Synchronization Server (Meta-Directory)
PingIdentity			PingFederate, PingTrust
Prodigen	Contouring Engine (Role Engineering and Enforcement Validation)
Proginet	SecurForce (Role-Based Provisioning and Delegation, Identity and Password Synchronization, Self-Service Password Reset and Registration), SecurPass (Password Management)	SecurAccess (Reduced SSO?? Not sure)
Quest	Provision (AD based provisioning and PAssword Management)
Radiant Logic	Synchronization Services(MetaDirectory)			Virtual Directory Server
RedHat				Red Hat Directory Server
RSA		RSA Access Manager (Web Single Signon and Access Control) RSA Sign-On Manager (Reduced Sign On)	Federated Identity		RSA SecurID Authentication (Strong authentication using One Time Password, USB, Smart Card)
SafeStone	AccessIT (PRovisioning, Audit and compliance)
Secured Service	Identiprise SecuredUser (Provisioning, Delegated Administration, User Self-service)	Identiprise SecuredUser (Policy Server)		Identiprise SecuredUser (Virtual Directory)
Securent		Securent Entitlement (Fine-grained access control)
SecurIT	R-Man (Role Management using Tivoli IDentity Manager)
Siemens	HiPath SIcurity DirX Identity (Self-service, Delegated Administration, Password Management, Provisioning)	HiPath SIcurity DirX Access (Web SSO)			HiPath SIcurity DirX - LDAPv3, DSMLv2 and X.500 Directory Server (Directory Server), DirX Identity metadirectory (Meta-directory)
Sentillion	Vergence Provisioning Manager	Vergence Single Sign-on (Reduced SignOn)??			Vergence Strong Authentication (Strong Authentication?), Vergence Privacy Auditor (HIPPA Privacy??)
SUN Microsystems	Sun Java System Identity Manager	Sun Java System Access Manager (Web Single Signon and Access Control) Solaris (Security module with file/LDAP/NIS/NIS+ based SSO and built-in extended ACL -Version 10) Java System Message Queue Enterprise Edition (Security module with file/LDAP based SSO and file based ACL -Version 3.6)	Sun Java System Access Manager(Federation SSO)	Sun Java System Directory Server Enterprise Edition Sun Java System Directory Proxy Server(Virtual Directory??/LDAP Firewall)	Sun Java System Identity Auditor
Symantec (Bindview)	Bit confused how identity integrates into this compliance.				Policy and Compliance Management (Define Policies), VULNERABILITY AND CONFIGURATION MANAGEMENT (Find holes on network and systems and apply Patches),
Symlabs			Federated Identity Access Manager (Federation)	Virtual Directory Server (Symlabs)
Trusted Network Technologies		Identity (Network Access control)
Vaau	Role Manager (Role Engineering and Management)				Identity Compliance (Compliance)
Veridicom					VKI (Strong Authentication - Finger print reader)
Vernier Networks		Edgewall series (NAC)
Voelcker	ActiveEntry (Provisioning, Self-service, password management)

Open Solutions		Sun Open SSO, Java Open Single Sign-On, CoSign, CAS(Use case), Pubcookie (Web Single Sign On - No Access Control a.t.m.),	Guanxi (Shibboleth)	OpenLDAP Software, Penrose (Virtual Directory)

Some companies in the "User-centric" Identity space

Looking forward to your input on the subject especially on open-source. Sources

Enterprise IT Identity & Access Management (Yale Li)
ID OSS Map (Jim Yang)
Daily news and conference like Burton Catalyst, RSA, etc
SSO

Why do you not need a provisioning solution?

2005-04-03T18:42:00.000-04:00

In this world of compliance driven provisioning implementation sometimes it may be worthwhile to really think about whether you need a provisioning solution in place. If the requirement is completly driven by the compliance, then how can provisioning solve the issue. Provisioning, most of the time, gives the idea that after implementation, company is going to create user accounts based on the Company's security standards and practices. But it does not provide by its very nature any way to stop rogue administrators from creating accounts, perform operations using that account and then deleting those accounts before the next reconciliation cycle. So it seems that from that point of view only feature that is of any benefit to the compliance driven implementation is provisioning product's ability to reconcile reosurce accounts (either real time or as scheduled task) in conjuction with a policy driven compliance enforcer (that most of the provisioning products are coming out with) which validates the information based on the defined policies.
If the requirement do surround the compliance then the implementation should completely be setup using audit log monitoring and alert products which then again goes to the idea that for that you do not need any provisioning product and instead a multitude of agent which have been installed as part of various security/monitoring initiatives in conjunction with existing BI/reporting products can be leaveraged for achieving the same result. With regards to that the idea would be to develop a good auditing infrastructure (which most of the products come built with) along with a good audit log aggregation and analysis system using some of the existing reporting and/or business intelligence products in the market. This may be better than implementation of provisioning products most of which are fairly new and immature in terms of these technologies.
Besides the incompatibility of compliance with provisioning products, another important aspect is its incompatability with the mordern 'SOA initiatives'. The SOA initiatives are based on the basic idea that access to a service is only through a very well defined interface accessible over well known protocol (like HTTP or Messaging Service). This allows the owner of the systems to create a very well defines interface as per business requirements instead of depending on interfaces provided by native products that they use. So going ahead the directory service group need not allow users to add, delete or modify entry directly into the LDAP. Instead they can provide a simple interface to do that then based on the internal directory structure, the interface will add the information into appropriate location. This allows the abstraction of the entire schema, tree structure and provides a more business centric view (vs technological view) of the service. As these SOA initiatives gain ground and start to grow (especially in this era of IT service outsourcing), it may not be a very crazy idea to stop using a technical interface (like APIs, LDAP protocol, etc) and start using the standards base interfaces (except when all the components are owned by single group or for performance/QOS considerations). In case such a world where the interface to these systems will be standard (to start of within company), the strength of the provisioning product in terms of adapter simply vanishes and we are left with an implementation that has a not so good workflow, rules engines and limited use of huge set of adapters which are not of much use.
Think about that!!

Of Delegation and Tickets

2005-03-20T07:43:00.000-05:00

It has been lingering in my mind for too long now but I was not sure whether the hypothesis had any base in reality or was it another arm chair thought. The idea deals with the two ways (I would love to use the word paradigm but will avoid doing so) in which the provisioning product interface have been designed.
Most of the products that I have seen started off with delegated administration in mind where a person (either manager or help desk) needs to perform operations on a single user based on the request that he/she receives out of band (verbally or by other electronically medium like email). The interfaces available to users were for self-service of personal attribute and/or password change . Besides that the idea was that there would be a only a subset of users that will perform the provisioning tasks.
Some how that was a underestimation of the processes already in place in most larger firms. Most of the large firms have a very well defined processes that can be initiated by any person in the firm by submitting either an edocument(like ticket) or a hard-document (signed by manager probably) to a ticket management system or help desk directly. The transition from the manual processes to ticket based system that mimic the manual process may be out of 1) respect for the existing process 2) resistance to and difficulties in setting up new processes 3) legacy of "automate everything" stage 4) any other. We have to understand that even though the existing process may not be the best way of doing things, it (which typically is very specific to a company) has withstood the test of time, laws and audits. At the same time end-user have a good understanding of the interface to the process. Overloading the end-user with understanding new glossary seems so unfair to them when they see the system as an enabler rather than end-all (which the provisioning team may see it as)
The request based system has its own advantages over delegated administration model. It provides an end-to-end tracking of the request generated by the end user in one place which greatly improves the QOS, responsibility and auditing tracking. Most of the delegration based access control that is currently in place is designed to give access to resource so that a help desk person from Germany should not be able to create accounts in US domain. I do not think the lack of provisioning technology was that big a factor to not moving to complete end-user based delegation model which is apparent from the lack of any in-house products at most of the places that I have worked at. Another reason for not moving to delegation based model could be that such a model does not support multiple changes being clubbed in some way for easy tracking and approval.
Now whether the implementation wants to go ahead with business process re-engineering or with implimenting the existing process, an important output of the requirement gathering process should be documentation of the existing process. Most of the time the end-to-end process is not well documented. Even if there are existing training material for help desks, the resource specific documentation (which is typically handled by resource administrators) is not well documented. This resource administration and management process is mostly passed verbally to next generation or is completely absent and relies on creating replica of the "referential" accounts based on the request from the person's manager. This is an audit and compliance nightmare. So understanding of the existing process can give a better understanding of potential holes in the process and may require handling of those issue (for example by setting up a synchronization in place or running weekly reports for access validation). Another important thing to consider after the documentation of the existing process is to consider what part of it can be optimized. At this moment I see that there would be lot of conflict between the vendor's architect and firms architect. The infrastructure at the firms have grown out of changing requirement at firm over 30 years (if the firm is that old and contains MainFrames). While at the same time, most of the product vendors assume a simple infrastructure when they are trying to develop the basic workflow. So, most of the time there would be a custom workflow required for the provisioning the accounts on those custom infrastructure. I was amazed to see the lack of this basic understanding in vendors and their suggestion that the infrasture be changed to fit into the product which would have required multi-million dollar investments.
At this point I am not very sure whether this is a generic principle that can be applied to any implementation or result of a few implementation that I have worked with. Need to do more investigation.

Shifting to the Blogger

2004-12-29T11:47:00.000-05:00

So finally I have decided to move to the Blogger from the JRoller due to a lot of issues that I was not comfortable with. I will be shifting all of my blog entries to this place over next few days.

Role, Role everywhere and not one is job description...

2004-09-18T20:45:00.000-04:00

It has been a long time since I blogged because I am working on another piece which is too broad and large and is keeping me away from the blogging on few quick topics that I wanted to talk about. Basically this topic comes is a result of a small discussion that I had with few people on Roles. The idea of Roles in theoretical world has been about job description (<self audulation>see here for more information</self audulation>). That is the role that you are assigned to should reflect the job description that you have. For example if you are having a job description of Trader then this is the role that all the applications should use to provide necessary access to the necessary resource. But just like what happens with a lot of other concept, the basic idea takes a complete backseat and the implementations are a different ball game. Based on infrastructure applications (especially portal infrastructures) that we seen in the wild, the number of roles that companies have are anywhere from 200 to 2000 (and counting) based on the number of applications that they have in production. Now it is perfectly possible that a multi-national corporation can have 2000 roles for a 50,000 to 100,000 employees, but that typically is not the case in most of the instances that we have seen. The culprit seems to be some thing else and that is the idea that role is a application specific entity rather than enterprise level entity. I am sure the people that have infrastructure in place already know what I am talking about :) In most of the cases that I have seen the roles are defined on application level and people are assigned to these roles to provide access. This architecture was great in the time when each application was on its own, developing the entire authentication and authorization functionality within their product. But with the new single sign-on and provisioning solutions that are being put in place this should have become thing of past. But that does not seems to be the case people have continued to use the roles as an application level access entity and taken the easy way out. I completely understand that meeting deadlines is not possible for the applications trying to integrate with SSO solutions, given that most of them may not want to integrate with the SSO in first place but have to do because top brass is pushing for it. But just like the push for SSO integration is coming from the top, some thought must be given to the idea of treating the roles as sacred entity like designation and try to implement the role structure. But again the corporate is not entirely to be blamed, because they will raise the question what about the legacy systems and third party applications that provide their own role model. In such scenarios the SSO and provisioning products have to step up to be able to provide role mapping facility on per application basis if they are being used to provide the information to application either at management(creation/update of identity) or at runtime (passing the roles/group user belongs to as header variable to backend application). Anyway the design of role itself in some cases shows the limitation of the product or thinking being applied. I have seen people design the roles which are self describing like read_all_accounts and trade_nse. Again this probably is more due to the limitation of the authorization products in market which do not provide very good framework for policy implementation.

Identity and Access Management - Part III Access Management

2004-06-26T20:40:00.000-04:00

In past few days a lot of discussions and past memories have resurfaced that has helped me bring together my ideas on the Access management piece of the Identity Access Management. So this is an attempt at putting together all those thoughts and ideas that I have heard from other people and some that I understood. See these locations for more details

Tutorial of American National Standard on Role Back Access Control
Types of Access Control
SACMAT
TISSEC(search for access control)

What is Access Control

Access Control is the mechanism by which a resource / object manager restricts the actions / operations that an identified user or Subject (including anonymous users) can perform on a resource or object based on predefined policy. Based on this simple definition we can see that following are the basic components of Access Control

Subject The person, process, any physical or logical entity or group of entity who can be identified uniquely in a Access Control system / domain.
Object / Resource The resource that the Subject wants to perform some activity on!
Action / Operation The activity (verb) that can be performed. These activity are typically valid for particular type of object i.e. you can "read"(action) a "file"(resource) or a "book" but to "read"(action) a "car"(resource) is meaningless in day to day conversation(somebody can always find a deeper meaning in to this type of reading).
Policy The policies are basically a system with a set of rules or axioms which have to be followed while making any decisions in a way similar to Riddles

What is Policy, Constraints and Context?

The Policy is a set of rules which are in following format "what actions the subject(s) can or can not perform on various objects under specific constraints" The constraints take into consideration the context in which access control decision is taking place. The policy allows the access control system to answer the following question as a yes, no or indeterminate "Can X(Subject) perform Y(Action) on the Z(Object) in the Context?" The context is additional information about the environment, subject, object and / or action that may be used to make the access decision. Let us take an example to better understand this concept. Lets assume we have access control system which has the following policy John(Subject) can play (Action) with the ball(Object) if color of ball is not black and it is evening(constraint) Looking at the constraint of the policy we can see how the attribute of ball(color) and environment(time to play) is used to provide the context in which this policy would be valid and thus provides constraint on the policy. So while taking the decision on whether to allow John to play with ball, access control system has to have the idea about what is the time when this decision is being made and what is color of the ball. Now given that we have a policy the we can ask the following questions to access control system "Can Adam(Subject) play(Action) with the ball(Object) given that color of ball is black and it is morning(Context)?" "Can John(Subject) play(Action) with the ball(Object) given that color of ball is blue and it is evening(Context)?" "Can John(Subject) play(Action) with the ball(Object) given that color of ball is black and it is night(Context)?" "Can John(Subject) play(Action) with the ball(Object) given that color of ball is blue(Context)?" "Can John(Subject) keep(Action) the ball(Object) given that color of ball is blue and it is evening(Context)?" "Can John(Subject) play(Action) with the bat(Object) given that color of bat is blue and it is evening(Context)?" This example should give an idea as to why the answers can be yes, no or indeterminate depending on the question asked and policy definition. Some time policy design tries to combine constraints with object or subject or action to achieve a similar policy. For example we can express the policy in the example above so that the policy does not have an explicit constraint and it looks like John(Subject) can play in the evening (Action) with the blue ball(Object) John(Subject) can not play in the evening (Action) with the black ball(Object) John(Subject) can not play in the night (Action) with the red ball(Object) John(Subject) can not play in the night (Action) with the blue ball(Object) Even though it is not a great example but we can see how the same policy can be expressed in variety of ways by choosing granularity of subjects, actions or objects and expression of constraints. This is a very important idea to keep in mind when designing an extensible policy.

Access Control Models

Over time a variety of access control models have evolved and a basic definition of the model can be found here. Over last decade the idea of Role Based Access Control has grown and to some extend reached a mythical status. We should concentrate on this model since this is what is mostly used for implementing access control.

Rule-based Role based Access Control

The RBAC is basically a brilliant idea of inserting another level of abstraction between user and policy so that users are assigned to roles and privilege (combination of action and objects) are assigned to roles. So instead of saying John(Subject) can play (Action) with the ball(Object) if color of ball is not black and it is evening(constraint) the role Child can be introduced so that A Child(Role) can play (Action) with the ball(Object) if color of ball is not black and it is evening(constraint) John(Subject) is a A Child(Role) This level of abstraction breaks the security policy into two parts i.e. defining the access control using roles without knowledge of all the users and defining the user - role relationship as the new users are added to the domains without changing the basic access policy. This helps a lot in evaluating the policy to find security holes and potential conflicts in access control. Besides that over time researchers have found that the idea of roles allows to build some additional rules into policy which may not be that simple to express in policies without roles. These additional concepts associated with RBAC are as follows

Hierarchical Roles[NIST] This basically is the idea of inheritance of roles so that
- Senior Role acquire privilege of their juniors
- Junior Role acquires user membership of seniors
So continuing our example if we define that Child role has 3 senior roles age(0-7), age(8-13), age(14-18) then
- A Child(Role) can play (Action) with the ball(Object) if color of ball is not black and it is evening(constraint)
- John belongs to age(0-7) implies
  1. John(Subject) can play (Action) with the ball(Object) if color of ball is not black and it is evening(constraint)
  2. John belongs to Child
The hierarchy can be as complex as required and roles can multiple senior and junior roles or it can follow simpler hierarchy like a role tree(where a role is allowed to have only one senior). Only important thing to remember is that there should not be any cyclic assignment so that a role is a senior and junior of itself due to role hierarchy. Another comment that I would like to make is getting hierarchy of roles correct is typically tough and thus people while designing the role hierarchy should either keep the role structure very flat or use the definition of senior and junior role to evaluate each role so that you do not make basic mistakes (like equating job hierarchy with role hierarchy).
Separation of Duty(SOD)/ Mutually exclusive roles / Policy Constraints[NIST & TISSEC] This is a very important idea especially in current environment where compliance, conflict of interest and chinese walls are the buzz words. The basic idea with regards to SOD is that some of the actions on the object can not be completed by same person; for example same person can not be accountant and auditor for the same company. The policy constraint is a super set of SOD in the sense that it refers to other constraints that policy must follow. For example a policy may have constraint that a particular role can not have more than 2 users and the access control system should be able to ensure that such rule is considered during role assignment. These policy constraint can be at the following levels
- User i.e. two person can not belong to same role or have same privilege or a role can not have more than X person / subjects(cardinal constraints). For example two persons can not check-in the same file from the version control system(after being checked out)
- Role i.e. same person can not belong to two separate roles. For example John can not belong to both age(0-7) and age(8-13)
- Privilege(Action & Objects) i.e. same person can not have two different privilege. For example John can not belong to both create and approve the same request but he may be able to approve requests created by other user.
- Constraints i.e. same person can not have two different privilege due to constraints. For example if John can not create requests which will cost less than 500 then he should be able to approve only the requests that are below 500.
NOTE:The constraint in research papers typically refer to Policy Constraints which are basically set of rules that may be applied at the time of assigning the users to roles or when establishing session(see implementation of SOD). This is different from the constraint that we discussed being part of the rule which are invoked during runtime to evaluate access permission. Even though I have specified the various possibilities above, some of them like constraint level policy constraints is something, I have not seen being discussed in either products or in papers on RBAC or access control for that matter(May be I am missing something). For that matter I have not seen a lot of discussions on constraints, as I have described here, in research papers. The implementation of separation of duty can be done in the following ways
- Static i.e. policy constraints validation is done at the point of assigning the user to role (a administrative function)
- Dynamic i.e. policy constraints validation is done at the point of activating the roles for the user. This function is an advance version of Weblogic Role Mapper. So the roles can be selectively "activated" and "deactivated" based on access requirements of the user or additional policy constraints(like both auditor and accountant role can not be activated at the same time or trader role can be active only between 9:30 to 4:30). NOTE: Discussions in literature tie Dynamic activation to User's Session making it similar to Weblogic RoleMapper (or may be I am interpreting it wrong). I think this is a under utilization of this concept (for example trader role where user can continue to have a session with the resource manager in same session but will have his trader role deactivated)

In the end I would just like to put down that RBAC is not solution to all the problems. Not all the policy requirement can be designed using Roles. For example take the case of a trader that is going on vacation and wants to delegates his responsibility to specific user. It would be easier to write a rule using user instead of developing role based access control. So even though the RBAC fits into most of the scenario, lets keep in mind that it does have some limitations.

Group vs. Role

This is a good old debate that keeps coming up given the similarities in the two. See here for a good explanation.

Policy Design

This is really a very large topic and I have not seen any best practice or even an introduction to this field. So this is mostly my understanding based on some experience I have. So basically most of the time the policy design is restricted by the rule design interface provided by the Access Control interface. For example if interface does not allow to use IP of the client in the defining rules then there is not much you can do about it :( So let us see what are the various interfaces that products provide for policy design and implementation.

Access Control List

This is one of the most common access control interface available in wide variety of products. It defines which users have access to what resources in a system. The complexity of the access definition varies a lot. The simpler models allow to define which user has access to what resource. At the same time the complex model may allow to allow or Deny particular action on specific resource for a user or a group. An important point to note is that typically ACL based systems do not allow you to write rule-based constraints. Due to the prevalence of this model, most people start thinking about Access Control using this model, which can be problem if you are designing access control for a rule-based access control engine.

Object Access Policy

This is an access control policy without the identity i.e. the access control applies to all the users. So for example anybody who is accessing a sensitive HR application should be required to sign-in using token authentication. The firewall rules to open specific ports can also be classified as Object Access Policy given that it applies to all the users that are trying to access particular ports of the systems. The implementation of this policy model may allow to write rule-based constraints, but at the same time the complexity of the rule that can be written or the attributes/environment variables that can be used in these rules varies a lot.

Rule-based Role Based Access Control

This seems to be the best combination of all the features of access control and at the same time one of the toughest to get right. A lot of SSO products are moving in this direction with different level of success. At the same time with increasing support for concept of identity in network, the network access control product like firewalls will also grow in this direction. The laws in recent years has made Privacy support in the products very important. The access control is a very important aspect of privacy management (though it has other aspects to it like data anonymity, data encryption and so on) and these privacy management product should also be a very good place to see how access control field evolves. Another evolving field in this area is the Digital Right Management which deals with the idea of how resource interacts with the resource manager to provide access control information which is then enforced by the resource manager. This field should be a good place to see how the things evolve.

Policy Constraints

Most of the policy design is done by using policy language provided by access control system to describe the business rules for accessing the application/resource. But most of the times these access control system comes with a default set of policy constraints(may allow to create these constraints) which must be followed by all the access rules. These constraints could be added to optimize the rules engine, reduce the number of indeterminate results(which may require manual intervention for correction) or to provide better security out-of-box. I will like to briefly put down some of these constraints that I have seen in wild.

Default Deny/Allow This is the basic policy that defines that if the access for a particular user can not be determined, deny/allow access to that resource automatically. Based on the security or manageability requirements, policy may provide capability to allow or deny by default. So for example if you are at home and some stranger requests your permission comes in, you are most probably going to deny the entry while if you are a casino owner in Las Vegas you are going to allow anybody to enter your premises unless that person does not figure on the Nevada's black book
Policy Override vs. Policy Inheritance The idea being that if some body has access to your house using a key it may automatically mean that the person has access to your bedroom (the bedroom being the resource that inherits the access control policy from the house), but typically will not have access to your safe which uses a different key( the access control policy of the safe over rides the access control policy of the house). This is not exactly a good example because the identity(i.e. the key to house) is different at each level, but it should give you the basic idea. A slightly better example can be a portal which provides access to a variety of application with each having its own access policy(but application trust portal to provide the identity) which require that you be granted specific permission for access. This means that the access policy of particular application overrides the access policy of the portal. But once you are into that application, the application may allow you to access any resource (policy inheritance by the application resource). This idea is based on the existence of a hierarchy. Even though this hierarchy is mostly used in the context of resources, it can as well be applied to group or roles (role hierarchy is basically the case of policy inheritance).
Deny overrides Allow This is a basic security constraint (and solves indeterminate cases) that is typically applied by the access control systems. This ensures that if the user has both allow and deny permission based on the policy, the access system will deny the access to the user.
Insufficient information implies DENY/Allow Some times the policy may require additional information to make a access control decision. For example if a stranger wants to get into your house for some discussion, but is unable to produce an appropriate badge, you may deny him the access. On the other hand, if you are owner of a hotel which is not required by law to verify the identity you may allow customers to stay even though they can not show a valid photo identity like car license(this is very much possible in parts of world, including newyork, where the public transport system is developed to a level that people do not need to have a car license to survive).

I will add more to this as I come across these constraints. Besides these policy level constraints, these are set of constraints that are applicable to resource(s) or role(s). For example a role can have cardinality limit so that a role can not have more than X numbers of subjects assigned or a resource has only specific set of actions that are valid (going back to the example that reading a car does not make sense). This(Section 4) has some good constrainsts as examples. This should give a basic idea about what the access control is all about!! Lets us try to look deeper into what Access Control Systems typically do in terms of implementation of these concepts.

Runtime

Most of the literature talks about two components of the Access Control Runtime i.e.

Acess Enforcement Point(AEP) which basically is the component of the resource manager that takes the appropriate actions to allows or denies the access to the resource. So for example in case of a Web Server, it could be a plugin that is invoked for every request being made and this plugin takes appropriate actions incase the resource can be accessed(like invoking another component to fetch and return the web page to requestor) or can not be accessed(returns the access denied page). Typically the AEP can be devided into two types
- Adapters - These are implementation modules that are specifically built to integrate with third party products which have published interfaces.
- API - The inhouse applications can use this inteface to utilize the ADP functionality without bothering to have to implement it in their product.
Access Decision Point(ADP) the component of the Resource Manager(or outside the perview of resource manager) which evaluates the policy based on the input from AEP, policy database and additional runtime sources and return whether the Subject should be allowed particular action on the specific resource i.e. it answers the question "Can Subject X perform action Y on Resource Z?"

These two components can communicate with each other using proprietary(like function call, IPC, binary protocols) or standard(XACML). I do not feel that XML is the best mode of communication because most of the time access control systems have to work in high performance environment where XML can be a big drag. At the same time it can be a component of a slower workflow based system which does not have high performance requirements. Another variation of using XACML could be by using its schema to develop a binary schema for query and response. Another important point to remember is the idea that AEP is separate from ADP and thus ADP should authenticate the AEP before it provides the decision or any additional information as the part of the answer. This is an important step to avoid the situation where a rogue AEP can access the ADP to understand the policy model or may even be able to extract information from ADP which can then be used to attack the access control system or the authentication system for specific identity (the idea being that if you know janitor has access to more rooms than CEO then you will try to get access to janitor's identity instead of CEO's identity). Anyway let us try to define a typical use case for the access control system

User tries to access a resource through its resource manager.
The resource manager's AEP verifies with ADP whether resource can be provided to anonymous user (this step does not take place all the time).
If the resource can not be provided, the User is required to identify and authenticated himself through the authentication module
After the authentication is completed, user is assigned a credential or a token (valid for the duration of session or specific time) which user can then provide to any access control module familiar with the token. The token allows us to design systems where the authentication and access control systems can exist separately and you are not required to authenticate every time you want to access a resource. This token typically contains all the information associated with the user that should be required to make access control decision (this may require the token generator to access a variety of repository, perform identity and attributemapping to generate a token that has all the relevant information) . This token can be a kerberos ticket on the network or a badge at the convention which allows you to access the premium seminars that you have paid for. Important thing to remember is that a token generated for specific domain is valid only in that domain. So you can not use your blockbluster pass to get access to pentagon. The security of token is a very important thing to be considered while designing them to ensure that token can not be counterfeited. It may also be important to validate the issuer of the token for trust purpose.
After it has been provided, the user can provide this token to resource manager for validation and resource manager's AEP, with help of ADP, can decide whether continue with the requested action / operation on the resource. In order to make this decision, besides the user information(typically part of the token) and policy data, the ADP may require additional information about resource and environment (the context of the decision) to make the decision. All the required information may not be available with the ADP and it may need to contact other repositories at runtime to gather all the information and then make the decision. At the sametime the AEP may also provide the information which are more contextual in nature (like client IP address, HTTP Request headers and so on) to ADP to complete the decision making process. This idea of separation of access policy and data required for evaluation is very important and can be exploited to build simpler systems.
The decision made by ADP is returned to AEP which will take appropriate action as determined. Some times the ADP may return additional information to AEP along with the decision so that AEP can use the information to provide appropriate resources to requestor. For example, in case of Portal Application, instead of asking "does user have access to Application A?" 100 times for 100 applications, AEP can ask the question "What application does user have access to?" and the ADP can return the information to AEP which can then use this information to paint the portal for the user.

Management

The management of the Access Control deals with

User Management This deals with management (Creation, Updation and deletion) of User (and associated information), roles and user's assignment to roles. The user information can be managed by the access control system itself or it can be managed in a separate repository and imported in to access control systems via push or pull model. The roles are typically are managed by the access control system and it typically allows to manage roles, their hierarchy and any additional constraints that may be applicable(like separation of duty). The User's assignment to roles can typically either managed by the access control or it can be provided at runtime (as part of the token for example). The static assignments are typically handled by the Access control systems and it may also provide ability to write assignment rules which are evaluated at runtime to get the list of roles that user belongs to (This is not very common so far).
Resource and action Management This deals with the managing the resource and associated actions. Even though there a variety of ways of modelling resources hierarchy, tree based representation is most common method with each resource with one and only one resource as parent and 0 or more child resources. Action is something which gets tied to the resources and product may provide capability to define the action set that is possible for a type of resource with resource belonging to a resource type.
Policy Design, storage and replication This is the core of the access control system. This provides the facility to create policies i.e. develop rules which allow or deny user or roles to perform certain actions on the resources under the given constraints. This management function also has to deal with how to store the policy thus developed and the procedure to use for making them available to ADP via push, pull or other model.
Policy Provisioning In the world of centralized policy management with hetrogenious ADP, the concept of provisioning the policy to these ADP become very important. So the idea is that policies are developed using a single policy model and then these policies are translated to the policy language understood by particular access decision point for enforcement. This can be very tough to achieve especially if features offered by the policy design system are advance than the legacy resource manager which may provide very basic support for Access Control modelling. Such constraints may require remodelling the policy or otherwise may result in partial implementation of access control .
Data integration even though this has been referred to in user and resource management, it is a very important piece of access control. This defines how the policy engine (ADP) gets the information that it needs during runtime to make the access decision. The data can come from
1. Requestor - in form of token or any additonal information
2. Policy Database - most of the policy database have provision to store and manage the information about user, roles, resources, etc. This information can be used at runtime for evaluation.
3. External/trusted repository - the policy engine may receive data from external repository via push or pull model during evaluation of the policy(at runtime) or in offline mode.
The management and ensuring the accuracy of the source of data is very important and data conflict may have to be solved (for example requestor and policy database both may have the same data with different values and it may be required to decide which data source take precedence )
Audit This forms a very important part of the Access Control. Even though most of the products generate some kind of audit, it is mostly left in the archives of the company vault till they can be destroyed according to the policy. But application audit monitoring in conjunction with IDS, IPS, honeypods (Intrusion technology) can be a very strong data mining tools. For example a consistent attack on an application can mean that intruder has been successful in compromizing the internal computer and thus can help to fight the attacks especially the one based on SSL Enabled protocols . At the same time the change in pattern of application audit should work as an alarm. But so far I have not seem at most of my clients any drive to bring these two technologies together and utilize data mining to generate patterns which can then be used by IPS for better management.

This concludes a brief discussion on the access control.

Identity and Access Management Infrastructure

2004-06-05T20:37:00.000-04:00

I have been thinking for some time about the possibility of developing an Identity and Access Management architecture using existing Opensource products. There where some ideas that I had with regards to component that I can use for example OpenLDAP and MySQL as Directory and Database respectively, Apache as the webserver and so on. But in order to do an end to end architecture, I thought of starting with a documented architecture which tries to accommodate as many IAM concepts as possible.
The image below is an attempt at the same and I already know that I have not covered all the concepts that I could think of. But at the same time, this would be a good exercise in understanding where the opensource is with regards to developing a complete solution.

Federated Identity Management Product or what you should remember when buying a product

2004-04-04T20:32:00.000-04:00

It has been a long time since I last wrote something, but FIM is something that I see people doing even without realising that they are doing it. I will try to list some of the use cases (which can be mapped to concept of profiles in SAML or Liberty world) that are part of the general specifications and some that are not. This article does not provide an introduction, but you can read here to better understand what I am talking about. Just like any previous article, I would like to break down the usecases into two parts

Runtime These usecases typically occurs every time the user hops between sites that are part of a federation(that has such a star-trek era feel to it). This typically deals with how the information is passed from one site to another site when the user is doing site hoping resulting in session establishment. Besides that it would also include auditing all these events for monitoring and reporting purpose.
Management These usecases basically talk about the management aspect of the FIM and typically would occur out-of-band/first time user accesses the new site/last time user accesses one of the site. This deals with the idea of token transfer protocol (including trust establishment between sites), the identity mapping between two sites and other configuration like authentication level mapping. These management events must be audited to ensure that all the changes can be tracked and used for policy enforcement validation.

Runtime

The FIM can be applied to a different categories of applications the most important of which are as follows

Web Based cross domain Single Sign On
Web Service Authentication
Client-Server or distributed applications with properietory protocols.

Rest of the article will discuss FIM as it applies to Web Based application with Cross Domain Single Sign On requirements. The basic use case can be defined as follows

User access site1.com and authenticates at site 1 using specific authentication method which sets up the context for the user(here after referred to as session)
User then clicks on specially formatted URL which generates a token and then redirects User to site2.com(via GET or POST)
On the Site 2, if token is not received via redirect, it is retrieved from Site 1 by Site 2. This token is then validated with regards to whether it is from site 1
After the token has been validated to be from site 1, the user information provided by site 1 must be mapped to site 2 and a context(session) would be setup with the information passed from site 1.
After the user has completed the work he would logout from Site 1 and which time the site 2 would be required to logout the user.

Management

The basic idea about the management is of identity federation and trust setup. Trust setup would typically be performed out-of-band. The identity federation or mapping the identities between two sites, can happen out-of-band or during the first visit to federated site. At the same time identity federation should also address the requirement to break the the identity mapping. These management setup may be performed as self-service or by administrator of two sites.

Components

Most of the FIM systems would consists of the following components as introduced here.

TRUST: The basis of all the FIM is trust. Besides the legal aspect of it, the technological aspect of trust can be established in variety of ways. Some of the simple ways to setup trust are
1. Shared Secret between sites
2. Public-Private Key pair and/or Mutually authenticated SSL between sites
3. User's IP address range(if site is being accessed from intranet for example) for access
4. contact Site's IP address range
5. ID/Password pair
Besides that the ideas are around with regards to third party Trust parties, trust brokering services and so on. I donot expect to see them in the market as requirement in near future.
Identity and attribute Mapping The identity from site A must be mapped to identity from site B at runtime. This mapping can be
1. One to One between the two sites
2. One to Many incase when the same user from one site may be administrator(for the company) and user of the other site.
3. Many to one incase the set of employees are given access to a paid site through a standard account id.
Besides the identity itself, the token can have additional information like user's attributes(like address, etc) and group/roles(at site A or site B). This information would be used by the destination site to build the context for the user. At the same time, the destination site can have it's own set of information about the mapped identity and may be added to the context for the user. With the concept of mapping and aggregating user information the following must be considered
- Whether site 1 information over-rides the site 2 information or the otherway.
- Incase of multiple identity matching how is identity selected (may be using simple rule like which domain name is being used or what is IP addresses of client to access web site. It may alternately provide identity choice to user)
Session Management Although session management has not been seen important from the point of view of standards, I think this is somthing that would be important in the wild. Some of the issues that would have to be addressed in the process would be as follows
- Session Timeout: This is about how the session timeout would be set for the federated site. Would that be based on the timeout of main site or decided by destination site.
- Session Logout: Even though the concept of universal timeout has been made part of the SAML 2.0, it does not addresses how the sites would manage concept of site specific logouts. This may be important from the point of view of Quality Of Service and service metering.
Authentication Module Even though the authentication is not part of FIM per se, the authentication mode is used by most sites to setup the access control form user. For example, the user may have been authenticated using basic Id/Pwd at the site 1 and then needs to access some information with higher authentication requirement. In such step-up authentication requirements the federated site may ask user to perform step-up authentication at site 2 or redirect user to site 1 for step-up authentication or may be just display access denied. In a large federation it would be important to decide whether the point of entry authentication be a specific site or would all the sites allow authentication using same information(i.e. ID password combination) and then allow the user to SSO to any other site that are part of federation. These issues also come into play in case of bookmarks(Passive Requestor Profile) for federated sites. When user tries to access the bookmark, the site in question may have to redirect to original site for authentication(if user is accessing particular Domain Name or URL pattern) or it may itself provide user to login into the its own site.

These requirements are some of the ideas that I think the products should provide. In next 2-3 years these use cases may appear in wild and we should be ready to solve them.

FIM(Federated Identity Management) based Security Services

2004-02-29T20:20:00.000-05:00

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

What is FIM?

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

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

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

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

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

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

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

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

SSO and Web Hosting companies/Telco

2004-02-22T20:13:00.000-05:00

Over last few months, something that I have been thinking why have the hosting companies not started providing sign-on services. It is a chance for both the hosting companies to provide this important service and at the same time allow the chosen vendor to prove how well its product works. But then after some deliberation this is what came out

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

So, these are my thoughts on the subject. Let us see how things really work out.

Identity and Access Management - Part II - Identity Management

2004-02-14T13:07:00.000-05:00

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

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

Incase you read the link that I provided in Part I, you have the basic idea about how identity has been defined so far as an abstract concept. In order to map this to more real-world scenario I have interpreted the three tier system in the digital world as follows

Core Identity: This is the digital representation of an entity in the domain. This needs to be unique in the particular domain and can be a UUID, email-id, employee id, or something that uniquely identifies the user in the domain.
"Action" Identity: This defines the identities that the core identity uses to perform its work. So for example the core user can use unix root id or a NYSE trader role. These identities are representation of the core identity in specific resource(s). Typically these identities are used by the resource manager to identify the user. These identities are typically mapped to core identity(or vise versa) during provisioning.
"About" Identity : Every identity has some information associated with it (like name, address, and so on). This information helps the resource managers in the domain to understand the core identity better and provide the resource based on the policies defined. I like to categorize this information into the following sets.

What is identity Management?

The basic idea behind identity management is to manage the three tiers of the identities that represent the entity in the domain. The core identity is the basic representation of the entity in the domain. The resource managers (which provide the functionality and data to the entity) due to various reasons may not recognize the the entity as the core identiy but as a completely different user id (for example root id on unix) or by the role the core identity has been assigned (for example unix admin role or NYSE trader role). These identities (the "Action" identity) would help resource manager recognize the user in its context instead of bothering about the core identity. This simplifies the job of resource manager in the sense that it does not need to know core identity of each and every entity to serve the entity. Once the resource manager has recognized the core identity in its own realm, it may need additional information about the identity to make decisions based on the resource manager policies. These decision can be about whether it should give access to required resource or what resources should it serve to the entity and so on... I like to classify this "additional information" in to three types.

Authentication Information - This information is needed by the authentication system of the resource itself or that trusted by resource to make sure that the entity is who it claims to be. This information can be
- What entity knows (like password)
- What entity has (like token generator, smart card, certificate)
- What entity is (like finger print)
The entity in this case can be a physical entity like user or a logical entity like an application.
Domain Information - The domain specifies that each and every entity's representation has a basic set of information associated with it. This may be information like name, address and so on. The decision about what , is typically made at domain level.
Resource information - This information is relevant only for particular resource only and does not make sense in case of another resource manager or will be used in different context in another resource. For example, the trade limit may make sense for an security trading application, but would not be relevant in a tax application and at the same time, may have different connotation in a forex application. This is typically defined by the resource group itself.

In the next section I will try to define what component typically come into play during the runtime i.e. when entity is interacting with resource manager to get access to resource and during management.

Runtime

The Identity management system should be able to help the resource manager identifing and authenticating the entity at runtime.

Components

The authentication mechanism can be broken down into two component -

Process: This is the moving part of the system which typically performs the following functions
- Retrieved the authentication/identification information using the configured procedure. This can be achieved by using a wide variety of ways like Basic Authentication, Forms based, fat clients, CSI-IIOP, Certificate, fingerprint scanner, IRIS scanner, Challenge Response like SPNEGO, SecurID and so on. An important part of the retrieval process is to ensure that confidentiality and integrity of the authentication information is not compromized in the process.
- Once the information has been retrieved, this information may need to be processed using specific algorithm (like hashing algorithm for one-way password or CRL validation for certificates) before information is in the form that can be compared to information in the database corresponding to entity.
- Besides that it validates whether the security policies regarding inactive account expiration, authentication information expiry(incase it is not biometric), number of logon trials, time and location of access by entity are being followed.
- Eventhough not part of core authentication, process generates the authentication audit events as configured.
Database/Directory: The trusted source of the authentication information with keyword being "trusted".
- The database should be designed so that the integrity and confidentiality of the authentication information can be maintained.
- The process uses the database to validate whether the information provided by the entity matches the information present in database. Most of the time this distinction about database being separate from process is not made. But it is important to realize that as we move toward SSO a very important strategy may comprise of having Single Database which is shared by different process which themselves are embedded in the legacy applications.
- These databases can be LDAP based directory, Active Directory, RDBMS, file system, ACE Server database, certificate store, to name a few.
- Once the distinction between Database and process is well understood, the next idea that should be kept in mind is how process interacts with database i.e. what are the databases that "process" supports, does the "process" provides facility to map the existing data structure/schema to its datastructure or does database schema need to be specific to the "process" being used.

Most of the times in the discussions, some thing that I have found missing is the concept of session. Basically, this is an important part of authentication and authorization but at the same time is not addressed in most of the specification. Typically it may be hard to define the concept of session, but in most of the cases the session can be defined as the duration during which the entity was interacting "actively" with the resource manager. The definition of "actively" is very subjective which may vary from few minutes for a user application's to days for long batch processing transactions. But for most of the applications, the concept of session inactivity timeout and session failover should always be kept in mind while considering the authentication which typically gets tied to session management.

Implementation

Based on the components that are described above the authentication runtime implementations can be broken down into following categories.

standalone component like Web SSO products or Desktop authentication where the authentication of the identity can happen even without the entity connecting to resource manager. In such scenarios the resource manager trusts the authentication mechanism and uses the identity(and additional information) passed to it to construct entity's identity. Incase of the standalone component it is important to understand the mechanism and security behind the transfer of user's identity to the resource manager from authentication process. This transfer can happen via Header variables(in case of Web applications), SAML, Privilege Certificates(PAC) and so on. Besides that resource may use different identity to identify the entity, in which case the user identity mapping would had to be performed by either the authentication mechanism or the resource manager.
Integrated component like built-in security module where the authentication happens when user tries to access the resource by contacting the resource manager. This is the most prevelant implementation before the Single Sign On concept came into the picture. The resource manager in this case has a built-in module that provides the identification and authentication facility. In addition to that these component provide the management facility(like identity creation, password reset). It is important that these applications are part of the single point Identity management strategy. Most of the provisioning product support the concept of adapters/connectors which allow you to integrate the identity solutions into these integrated component using component specific APIs or standard protocol. Incase the database of the component is built using a standard RDBMS or Directory, Meta-Directory products are available which can synchronize the information between the products. A very important point to remember is that the identity information can flow both ways i.e. from central repository to resource manager's identity database and vise versa.
Shared database This catagory falls between the two approaches described above. A lot of new inhouse applications typically take this approach. It allows the authentication process to be integrated with the resource manager but uses a database that is not under complete control of resource. A good example would be Unix box using LDAP/Kerberos for authentication purpose. The process uses the available database (which may be managed via other process) for validation of authentication information.

Management

The identity management deals with the process of addition/modification/deletion of the identities and associated information. There is nothing new with this concept, and for years the resource managers have provided built-in components that do exactly the same and enterprises have developed systems in their operations department that use workflow applications to manage this process. These systems typically work as follows

A request paper work was submitted or a ticket was create via helpdesk. The help desk/operations department used the workflow product (like REMEDY) to send the ticket to appropriate administrator. The administrator then performed the identity management operation on the application using the application's administration interface.

This approach has two things missing

End-to-end automation Due to the human factor a lot of time the tracking, auditing, accountablitity is not exactly the best thing about the process. So it would really be great to have an end-to-end system that can allows tracking, auditing the complete process and give accurate status of the process. One of the ways is to automate the complete workflow and include all the entities involved in the process(users, their manager, resource owner). This is an important contribution of the latest breed of provisioning systems. This frees the administrators of the dreaded work of reseting password and concentrate on application administration.
User Interaction An important part of the previous workflow systems was dependency on third-parties like help desk/ system administrator for the completion of the work. The new products bring in the concept of self-service where the user can perform the basic administration tasks like password reset, creation of accounts to some systems( once they have basic privilege) without requiring input from third parties. It is very important to design the workflow so that the confidentiation and integrity of the systems is not compromised for example the password reset workflow should be designed so that only the person who is the owner of the account is able to perform the reset(this is typically implemented in variety of ways like using known email id, personal question/answer).

Components

Most of the client being used to concept of ticket tracking expect similar functionality from the identity management systems. Most of the old ticketing systems allowed users to provide free-text input which was meant to be for human administrators. This is I think the biggest hurdle in new systems where the complexity of the ticket that can be generated during the process is very limited and should improve over some time. Eventhough the level of functionality may vary with implementation, most of the products have the following component in some form or other as part of their implementation.

Interface is, understandably, an important part of the identity management. There are two parts of the interface - input and notification. The input basically deals with interface(like web based, fat client, APIs, Web Service, SPML) using which the users and other process can interact with the identity management application to provide input required for the workflow to complete. Most of the workflow have various points at which it needs user input(like approval of a request, additional information) and at those point the IDM application needs to notify the user via different kind of interfaces (like email, lotus notes, groupware, pager, and so on). So it is very important that identity management should have an appropriate blend of the two interfaces.
Delegation is an important part of the operations. This allows the help desk to manage a lot of the basic facilities and free the application administrator from it.
Rule/Policy Engine Most of product support some sort of rule engine. This is important part that helps designing the rules that can be associated with input validation and choice of workflows and so on while implementing complex processes.
Workflow engine This is one of the most basic thing that every identity management product that provides complete solution has. This helps the defining the business process for identity management and automate them.
Trusted Repository Most of the enterprises already have a separate systems that manages the employees(HR ERP), customers (CRM) and so on. These identity must be accepted by the identity management system as trusted identity and hence the concept of trusted repository.
Reconciliation/provisioning Adapters/Connectors Well these are the components that complete the automation. Basically these are the components that connect to the resource managers or its security database and add the identity information to it.

These components typically form part of the identity management systems. Next time I will try to take up the Access/Authorization Management systems.