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

I’ve been looking at how people have been implementing input validation and entitlement evaluation within service-oriented architectures (SOA). One of the nice properties of an SOA is service composition, so transformation and validation can be implemented as an independent utility service and then composed with other services. But service composition has the drawback that one must remember to compose, so in some implementations input validation is implemented through an interception mechanism rather than through composition.

Another example of this interception technique is visible in some XACML implementations. In XACML, the Policy Enforcement Point (PEP) is decoupled from the application logic. Several of the implementations of PEP’s I’ve looked at use some form of interception in front of the web service to hook the service invocation. The PEP can then extract the information it needs to perform the entitlements check.

This interception technique raised the question amongst one of my colleagues as to whether using such a scheme represented “bolt-on” security or “built-in” security. I believe that the concern is that, when used for input validation, the interception mechanism allows the validation to be done outside of service. In fact, the validation can be developed even after the service has been deployed.

I argue that this mechanism is “built-in” and not “bolt-on” security. I believe that this technique merely represents an extension of the aspect-oriented programming (AOP) concept of a cross-cutting concern within the context of a service-oriented architecture. It’s like “aspect-oriented service architecture.” Having aspects within a service-based architecture is good for all of the same reasons that aspects are good within a programming framework.

Now, I’m not suggesting that all uses of interception can be classified as “built-in.” I think that for such security aspects to be considered “built-in” that there must be some level of binding between it and the action. For example, for input validation to be considered “built-in,” the validation aspect must be able to have access to all of the input data values and must perform specific validations based on the semantics of the service being invoked. It’s not sufficient to have some lame black-list filter that looks for “<” and claim that this is “built-in” security. No, the input validation aspect must know about the data types and semantics of all the data coming into the service and have specific validation for each datum.

Maybe I’m over generalizing the notion of cross-cutting concern in service architectures. Maybe these two aspects (and they are conceptually closely related) are the only two aspects that can be factored out of the application logic so cleanly. But, just because they can be factored out and implemented independently from the application logic, I don’t think that the factoring justifies it being called “bolted on.”

Technorati Tags: soa, software security