Aspect-Oriented Service Architecture: “Built In” or “Bolted On” Security?
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
March 1st, 2007 at 3:45 pm
This is a very good discussion, bolt on is usually seen as something to be avoided, but the reality is that virtually every security mechanism is going to do something like interception to mediate the activity between the subject and the object it is protecting. The question is how close to the object does this occur, and how closely does your PEP map to the objects it protects? The thing that XACML and other message level security mechanisms address is they are mapped to the actual schema, so from a process point of view the PEP may seem bolted on but from a data point of view it is anything but. Furthermore, SOA is about interoperability at the message level, and no amount of so called “built in” input validation protects that message over the hops it has to make.