Tuesday, November 13, 2007
Enterprise Architecture and the Confused Deputy Problem...
Programs generally take actions on the behalf of other programs or people. Therefore programs are deputies, and need appropriate permissions for their duties. The confused deputy problem happens when the program applies permissions that it has for one reason for the wrong reason, and therefore allows something that it shouldn't...
A classic example involves a program that needed write access to its licensing information so that it could track usage. The problem came when the user accidentally asked the program to remove the contents of a folder that happened to contain the licensing information. The program should not have done that, but had the necessary permissions and did. A more up to date example would be a program that needs read access to the local file system to get information needed to display information, but which can be tricked by the user into reading part of the file system that it should not, for instance displaying /etc/passwd. Many more variations exist.
Generally, people say that this happens because the application had security holes or was poorly coded. However, when constant vigilance becomes necessary to keep things from going on, it is good to find a more fundamental cause. In this case, a more fundamental cause is that no direct connection is maintained between what the application does and why it has permission to do that.
If you look at modern security approaches, you may conclude that the better answer is to leverage XACML where each enterprise application (e.g. BPM, CRM, ECM, ESB, ERP, etc) implement a common grammar for how access control is modeled, such that it enables runtime conflict resolution and reads more like a business requirement than a confused list of flags we know as access control.
Many software vendors have been negligent in terms of designing their own code to centralize authorization decisions via a standardized interface and have spread authorization decisions throughout. A good question that should be added to RFPs sent to vendors such as EMC, Oracle, CA and others, is to ask when will they support XACML on their roadmap. If you detect hesitation, it may uncover a suboptimal product design that they don't want others to know about.
Within the open source community, since source code is transparent, a good example of doing it correctly is Liferay Enterprise Portal where if you decided you wanted to support a different model for authorization, you can simply extend the PermissionsChecker class and you are off to the races.
Sadly, software vendors in the ECM space such as Stellent, Documentum and Alfresco don't incorporate such a notion in their architecture. Nuxeo is the only ECM platform that doesn't suffer from this deficiency, yet you won't even hear this from industry analysts. The news is even worse in the BPM space where players such as Intalio, Lombardi Software, Filenet, Pega and others aren't even having the conversation as to ways to change their security model for the better. I assume that if enough customers uncover the problem with ACL-based models, that will change very quickly.
Anyway, if you have to spend time figuring out how to connect what the application does and why it has the permission to do that and not thinking about how it would increase productivity by having the ability to simply declare a policy using a standard grammar then you to are a confused deputy...
| | View blog reactionsA classic example involves a program that needed write access to its licensing information so that it could track usage. The problem came when the user accidentally asked the program to remove the contents of a folder that happened to contain the licensing information. The program should not have done that, but had the necessary permissions and did. A more up to date example would be a program that needs read access to the local file system to get information needed to display information, but which can be tricked by the user into reading part of the file system that it should not, for instance displaying /etc/passwd. Many more variations exist.
Generally, people say that this happens because the application had security holes or was poorly coded. However, when constant vigilance becomes necessary to keep things from going on, it is good to find a more fundamental cause. In this case, a more fundamental cause is that no direct connection is maintained between what the application does and why it has permission to do that.
If you look at modern security approaches, you may conclude that the better answer is to leverage XACML where each enterprise application (e.g. BPM, CRM, ECM, ESB, ERP, etc) implement a common grammar for how access control is modeled, such that it enables runtime conflict resolution and reads more like a business requirement than a confused list of flags we know as access control.
Many software vendors have been negligent in terms of designing their own code to centralize authorization decisions via a standardized interface and have spread authorization decisions throughout. A good question that should be added to RFPs sent to vendors such as EMC, Oracle, CA and others, is to ask when will they support XACML on their roadmap. If you detect hesitation, it may uncover a suboptimal product design that they don't want others to know about.
Within the open source community, since source code is transparent, a good example of doing it correctly is Liferay Enterprise Portal where if you decided you wanted to support a different model for authorization, you can simply extend the PermissionsChecker class and you are off to the races.
Sadly, software vendors in the ECM space such as Stellent, Documentum and Alfresco don't incorporate such a notion in their architecture. Nuxeo is the only ECM platform that doesn't suffer from this deficiency, yet you won't even hear this from industry analysts. The news is even worse in the BPM space where players such as Intalio, Lombardi Software, Filenet, Pega and others aren't even having the conversation as to ways to change their security model for the better. I assume that if enough customers uncover the problem with ACL-based models, that will change very quickly.
Anyway, if you have to spend time figuring out how to connect what the application does and why it has the permission to do that and not thinking about how it would increase productivity by having the ability to simply declare a policy using a standard grammar then you to are a confused deputy...
