Identity and Access Management

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

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 wit

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

Update September 6, 2015: Part II in the series is now available . Update August 19,2006: I am rewriting this entry based on the methodology I am using for some of other domains. Hopefully, the new methodology would make it more useful to some of you. I talk to a lot of people from developer background who still do not have a good background in the IAM technology. Eventhough there is a lot of information on the web, I have felt a lack of good technological discussion on the various component that  actually form the IAM domain. Some of the good sources for the information on IAM are Microsoft Identity and Access Management Series Archie Reed Oracle Federated Identity Buyers guide Oracle Identity Management Buyer's Guide Identity Management Dissected 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 manage

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

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

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

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

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 implementation

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 va

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

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 bro

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: