Wednesday, July 11, 2007
The value of entitlements management
Many enterprises are starting to realize that identity management is starting to run out of steam and they need to consider entitlements management as the next step...
ECM, BPM and CRM vendors are starting to realize Better Application Security through XACML. Many of these vendors have realized there are significant limitations in terms of using ACL-based approaches especially when they need to integrate with external systems.
Identity Management products have sold their offerings under the guise of helping enterprises report on access to enterprise applications but haven't told the entire story. One needs to ask themselves whether reporting and/or provisioning on identity and attributes alone is sufficient or will your auditors sooner or later also require you to report on authorization constructs as well.
Identity Management goes after low-hanging fruit as most identity information is centrally stored in Active Directory, RACF or similar systems whereas authorization tends to be embedded within enterprise applications using a variety of approaches. One should noodle whether the right thing is to encourage a proliferation of proprietary adapters in order to make identity management a reality or whether the enterprise is better served by asking their enterprise vendors to extend expose their authorization models using industry standards.
There are essentially two ways one can approach entitlements. The first is top-down where you first have to create a strategy that is best realized not through actual implementation but in drawing pretty four-color chock-a-block eye candy PowerPoint presentations in order to help gain buy-in. You will of course need to spend at least $300K to get these PowerPoint presentations done by a large consulting firm who will back up the school bus and help you conclude what your enterprise architects have always known. You can also do something more pragmatic by instead focusing on implementing entitlements management within your enterprise applications which will buy you the ability to consistently enforce security policies and expose them for consumption to your identity management tool.
The notion of role modeling and engineering is one of the biggest traps ever witnessed. Gunnar Peterson describes the notion of Role-Based Access Control as when one maps subjects to roles to entitlements for certain objects/resources which sounds a lot easier than it is in pracice. Many organizations look at the model and say "hey I know that if you are a DBA then you are in this role and you should get this type of functionality, and if you are a sales person you are the sales role and get only these functions." The problem is that mapping, while not always trivial, is by far the easier. Mapping all the object to entitlements and roles is very difficult in a distributed system.
Role modeling is the Vietnam or Iraq of IT, keep sending troops and resources, but good luck solving the problem. How RBAC is typically practiced in distributed system often quickly devolves into a game distributed impedance mismatch. Roles can still play an important part in the overall access control model, but they are not generally sufficient alone.
It is somewhat intuitive that enterprise architects already have been thinking about this perspective and the expense of pain felt by enterprise software vendors. I wonder if software vendors in the world of identity management realize that they may be better served by extending the conversation to include integration with other standards outside of their control vs solely focused on their insular view and otherwise exercising their right to remain silent. I hope that the identity 2.0 community realizes that they are really doing identity 1.0.2 and that to really claim identity 2.0 they need to consider authorization models based on standards as part of their message...
| | View blog reactionsECM, BPM and CRM vendors are starting to realize Better Application Security through XACML. Many of these vendors have realized there are significant limitations in terms of using ACL-based approaches especially when they need to integrate with external systems.
Identity Management products have sold their offerings under the guise of helping enterprises report on access to enterprise applications but haven't told the entire story. One needs to ask themselves whether reporting and/or provisioning on identity and attributes alone is sufficient or will your auditors sooner or later also require you to report on authorization constructs as well.
Identity Management goes after low-hanging fruit as most identity information is centrally stored in Active Directory, RACF or similar systems whereas authorization tends to be embedded within enterprise applications using a variety of approaches. One should noodle whether the right thing is to encourage a proliferation of proprietary adapters in order to make identity management a reality or whether the enterprise is better served by asking their enterprise vendors to extend expose their authorization models using industry standards.
There are essentially two ways one can approach entitlements. The first is top-down where you first have to create a strategy that is best realized not through actual implementation but in drawing pretty four-color chock-a-block eye candy PowerPoint presentations in order to help gain buy-in. You will of course need to spend at least $300K to get these PowerPoint presentations done by a large consulting firm who will back up the school bus and help you conclude what your enterprise architects have always known. You can also do something more pragmatic by instead focusing on implementing entitlements management within your enterprise applications which will buy you the ability to consistently enforce security policies and expose them for consumption to your identity management tool.
The notion of role modeling and engineering is one of the biggest traps ever witnessed. Gunnar Peterson describes the notion of Role-Based Access Control as when one maps subjects to roles to entitlements for certain objects/resources which sounds a lot easier than it is in pracice. Many organizations look at the model and say "hey I know that if you are a DBA then you are in this role and you should get this type of functionality, and if you are a sales person you are the sales role and get only these functions." The problem is that mapping, while not always trivial, is by far the easier. Mapping all the object to entitlements and roles is very difficult in a distributed system.
Role modeling is the Vietnam or Iraq of IT, keep sending troops and resources, but good luck solving the problem. How RBAC is typically practiced in distributed system often quickly devolves into a game distributed impedance mismatch. Roles can still play an important part in the overall access control model, but they are not generally sufficient alone.
It is somewhat intuitive that enterprise architects already have been thinking about this perspective and the expense of pain felt by enterprise software vendors. I wonder if software vendors in the world of identity management realize that they may be better served by extending the conversation to include integration with other standards outside of their control vs solely focused on their insular view and otherwise exercising their right to remain silent. I hope that the identity 2.0 community realizes that they are really doing identity 1.0.2 and that to really claim identity 2.0 they need to consider authorization models based on standards as part of their message...
