Externalizing Access Control Quandary
This entry started as an email to a co-worker: Will. I’ve edited to make it a bit more readable, but in an attempt to blog more often and less formally, I’m only applying the thinnest editing veneer. We were discussing whether (again) moving entitlement/access control decisions out of the application code really made sense. Will was concerned about not making the developer responsible for implementing access control for an interface. I’m putting words in his mouth, but how can one “build in” security if the responsibility for one of the more fundamental security controls is taken away from the developer?
The notion of externalizing the access control is spot-on from a design standpoint. There are many reasons to externalize and one can argue that many of the problems with web application security is that the auth/auth got shoved into the application and the application developers were not qualified to write such code.
I think what was making Will nervous was the question of WHO makes the decisions when configuring this externalized mechanism. It’s also the case that WHEN do these configuration questions get handled. The answer to date is that there is some sys-admin or app-admin that does this after the application is deployed.
Historically, this hasn’t been done very well and/or the RBAC systems put in place to configure and manage such auth decisions have been notoriously difficult to administer at scale. I will, however, say that one of the arguments for externalizing the mechanism is that the job of implementing auth/auth requires more than the PDPs/PEPs in the app; it’s all of the additional software for managing/updating the PIPs where the bulk of the work resides in building a robust access control mechanism. Again, the app-dev guys aren’t the best person to write all of the management software and you wind up with the problem where administrative functions is just a series of configurations handled through a command shell or your favorite editor.
This still doesn’t properly answer the question of WHO. Admins don’t have the knowledge to properly configure and the developers don’t have a proper notion of who should be using the interfaces they create.
This is really an architects job, but while the architect has the breadth of knowledge to make the decision yo (trying out this new gender-neutral pronoun) lacks the tool to understand the actual interfaces that exist. The architect will have pre-defined about 80% of the actual interfaces, but the implementers will have created others to solve implementation level problems. So, 20% of the interfaces will be entitled without much thought.
So, let me make another point of externalizing the auth/auth mechanism. That is what we need here is a tool that can turn all of the code into (UML) descriptions of all the interfaces. We need to decorate that list with the entitlement data, but we can only do so if there is a canonical way for the tool to read the entitlement information about said interface. If we can do this, now we’re cooking with gas since we could then write some kNN-like algorithms to compare each interface with other interfaces like it so we could see where there are potential, logical inconsistencies.
Technorati Tags: access control, entitlements, design, architecture
