Yesterday, I blogged about the Security Triangle, which is a different way of thinking about security, instead of thinking about security as "one thing" or a state of being, consider the three core concerns of Identity & Access Services (letting the good guys do their work), Defensive services for a Margin of Safety (keeping the bad guys out, limiting their impact), and Enablement (bundling and delivering for the real world).
Farhang Kassaei has a very useful post on security decision making that gets to many of the same concerns
For every question/decision we designate one engineer as "good guy" and one engineer as "bad guy" and we ask each how this decision help or hurt you. I emphasis that it is critical to think and view a decision from a bad guy point of view. Most of us are basically not fraudsters and think in terms of "getting things done" and "being helpful", we rarely look at a feature and think to ourselves "How can I abuse it" (if you do, please contact me, I may have a job for you), so we assign an engineer just to do that.
Of course we want all our decision to be just as shown in the figure above :Help good guys and hurt bad guys. But that is not always the case, take using the embedded browser (and not a full pop up) to perform OAuth. This decision looks more like this:
Whereas blanket words like "security" and "trust" are quite harmful to design and architecture, breaking down the concept of security it quite helpful. These types of decision frameworks are very helpful to making rational decisions on security architecture.
I do a fair amount of work with Web Services Security. One question that inevitably comes up is - "why do we need a XML/Service Security Gateway"? We have Oracle/IBM/.Net/Apache app servers and they handle the type of SAML enabled access that the security arch spec says we need, so why do we need a gateway like IBM DataPower, Intel SOA Expressway or Vordel?
The answer can be found in the Security Triangle. For example, let's say you specify your Web Services use SAML. Most app servers will support this and so you may think "well I have the SAML token, this gives authentication, integrity, encryption and more or less exactly what I need for security." But while this is in fact a good start on Web services access control for authorized users, it does basically zero to keep out attackers. In fact publishing a vanilla App server on the Web means the attack surface is available to misused in various and sundry ways. So SAML-enabled Web services served up in a vanilla App Server container deliver on the first part of the triangle - Identity and Access Services, but a Gateway is still required to deliver the Margin of Safety through attack surface reduction; as well as content security validation, escaping and encoding performed in a separate process and memory space.
So, yes the vanilla App Server Service Provider handles SAML, but it also handles many other things, that's what app servers, and ESBs, are - giant aircraft carriers that do many many things, one of which is serve Web services. From an Identity and Access standpoint we want standards like SAML, but Defensive we don't want a bloated attack surface and we want to isolate our security pipeline processes. This is where the Gateway comes in.
Interestingly enough - Enablement - the top of the triangle is served by the Gateway as well, because the Identity and Access and Defensive services can be accomplished in specially tuned parsers and hardware. Going back to Farhang's decision making framework, Gateways give us a way to help the Good Guys and hurt the Bad Guys. Security people dealing with Web services (aka Mobile, Cloud or any other new technology) will be well rewarded by time spent designing and deploying Gateways.