Identity and Access Management

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

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 Voic

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.

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