Identity and Access Management

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.

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

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 / dom

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.

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

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 reaso

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 t

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 manage

What Consumer Want or Problem Definition Well sometimes even they don't know! But objectively looking at the problem definition can be stated as : "Enterprise have a large number of resources that need to be a accessed by a large number of user. With increasing number of resources being accessed by each user and each resource being controlled and managed by business groups, the following is some of the pain each of the party is going through End User pain : the number of identity that the user need to remember to access each resource is increasing Management pain : Management does not have a clue(leave alone controlling) on what user has access to on a day to day basis and they have the auditors / compliance officers breathing down their neck. Operations pain : Operations spending more and more time in correcting the mistakes of the users(like password reset), management(get me report for user access and make sure that all the security policies are followed) and followin