Identity and Access Management

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 th

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 Polic

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 tryin

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 pr

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

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.

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 (RADIU