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

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.

Comments

Post a Comment

Popular posts from this blog

Vendor List

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, Mainfra...
Read more

Understanding IAM Technology: Web Single Sign On (Web SSO) Part I - Introduction and Use Case Definition

Image
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 m...
Read more

Reclaiming your account: Password Reset/Forgot Password

Image
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...
Read more