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.