When SOAP-based Web Services solutions began appearing five years ago, one of the major challenges was securely propagating end-user identity in Web Service chaining scenarios. Certainly a user could authenticate to a portal, and that portal could talk to a Web Service that talks to another Web Service that talks to another Web Service (and so on), but the big question was - how could each point in the Web Service chain be assured who the requesting end user really was?

Initial trials of identity propagation solutions became like the "Kevin Bacon game." The assurance of the end user's identity would be based on trusting each connection in the chain and, as we know, there's no limit to the number of Web Service hops that could occur before the lifecycle of a SOAP request reaches its final destination. Much like the game of "Pass The Secret" that we play in kindergarten, where a secret is whispered in one ear and passed around in the room, there was little assurance that the final recipient had the right information.

Years later, SOA security architects now have blueprints for propagating end-user identity and attribute credentials in a multi-tiered SOA environment. Leveraging mature standards such as XML Signature and SAML (the Security Assertion Markup Language), the WS-Security SAML Token Profile provides a mechanism for trust propagation in Web Services. This standard, along with other similar token-based standards, give us opportunities and choices related to access control management and enforcement in the enterprise.

Because of these Web Service security standards, we've moved from the problem of asking, "How do we know who the user really is?" to "How do we enforce access control policy for this user?" Leveraging identity propagation standards in Web Services, there are usually two common approaches of SOA access control policy management:
1)  Centralized Approach. Using a "Yes/No" policy server, a handler or component enforcing access control for a Web Service looks at the propagated identity and must call a central server essentially saying, "Can user X access this Web Service?" This model, shown in Figure 1, is completely centralized, as it involves centralized management of all access control policy, and also centralized decision-making.

2)  Decentralized Approach. Completely different from a "Yes/No" policy server, Web Service containers express, manage, and enforce local policy based on global identities and attributes propagated to the Web Services. In this model, shown in Figure 2, a handler or an enforcement component inspects the identity and attributes propagated to the Web Service, does a local lookup on the Web Service policy, and makes an enforcement decision. This model is completely decentralized because it uses decentralized management (management expressed by each Web Service container) and decentralized decision making.

Pros and Cons of the Centralized Approach
The centralized approach is the most common as anyone can see by looking at the enterprise policy server market. There are several benefits to this approach:

• Information Hiding. From a security perspective, a completely centralized approach leads to information hiding, which can be a very good thing if you want your reasons for access control decisions to be secret. (That is, if you ask the question, "Can person X access resource Y," you get a response, but you don't really know the reason for the response.) This is also beneficial if you only want identities to be propagated and not necessarily the attributes about users to be propagated, if any of these attributes are confidential.
• Complete Control. Finally, if you have a central point in your enterprise that makes all the decisions, the administrator has centralized control of everything, where access control changes for all enterprise Web Services can be made with the touch of a button, which is a great thing. A centralized policy server making all access control decisions means that you also have centralized auditing, which is a lot better than having to look through the logs on the machines throughout your enterprise.

  Having listed these benefits of the centralized approach, there are also potential pitfalls:

• Poor Scalability. If an enforcement point for every Web Service in your enterprise needs to make a call to your policy server for every access control decision, there will be a large load on that server, and you'd better hope it never crashes. This is a potential Denial of Service (DoS) attack waiting to happen. If your policy server does go down, you need to ask yourself - "Should I give access to everyone, or should I deny access to everyone?" Believe me, you don't want to go there.
• Poor Performance. If policy enforcement points for your Web Services have to make network calls to a policy server for every access control decision, it will slow your applications down. Calls to policy servers must be cryptographically protected, since the enforcement point will need assurance that it's talking to the policy server and that there's message integrity in the message response. The result of this added network call and cryptography will be poor performance. Certainly your local enforcement points can cache these policy decisions for a certain amount of time to avoid repeated calls to the policy server for the same user, but the cryptographically protected initial calls to the policy server - combined with what will surely be a heavy request load on that policy server itself - will lead to your applications slowing down.
• Potential Management Burden. If you choose a centralized policy server model, this means that there will be one point in your enterprise that makes all access control policy decisions. And this means that either your policy server connects to other servers to get those policies for every Web Service in your enterprise, or your central policy server will have to manage policy for every enterprise application, which could be a heavy burden.

The benefits of this approach are obvious - by doing this, we eliminate all of the pitfalls of the centralized management approach. Instead of having to ask "Mother may I?" to a policy server every time a decision has to be made, a local Web Service handler is empowered to make a decision based on the identity propagated in and based on the local policy expressed by the Web Service itself. No policy server needs to be running using this model, eliminating the concern of the policy server being a bottleneck or a performance burden. In this model, each Web Service container manages its own policy - eliminating a potential centralized management burden.

Having said this, there are also potential issues with this approach. By moving to a completely decentralized model, we lose the benefits that the centralized model adds. Most importantly, there is an issue here of control. In an emergency situation, where a policy change must be made to deny access to security violators, how could we quickly lock down and protect every Web Service from those security violators when using a completely decentralized model? Would the enterprise administrator have to call up every Web Service provider, asking him to change his policy?

The lack of control that a completely decentralized model brings is problematic. As a result, there's a need for a different model that leverages the pros of each of these approaches.

Best Practices
At this point, I've discussed two common models - completely centralized and completely decentralized. There are benefits to each, but there are serious pitfalls associated with each model. These are, in fact, two extremes, and yet they are still the most common models for SOA security access control policy management. The dilemma we face is that neither model offers us the best solution.

The answer to this dilemma involves creating an architecture that merges the best of centralized policy management and the best of delegated decision-making eliminating those architectural items that lead to pitfalls. This article proposes the following:
1)  End-user credentials are propagated in WS-Security messaging using one of the token profiles

2)  Global Security Policy is managed by a central authority and syndicated to local policy decision points

3)  Local Security Policy is managed by Web Service owners (optional)

4)  Local Policy Decision Points enforce locally stored local and global security policy based on credentials propagated in Web Service calls

Figure 3 shows a diagram of this model that in most cases will represent the best of both worlds - taking some things from the centralized approach, and some from the decentralized approach.

This model answers many of the dilemmas discussed so far here by using a policy syndication server. If we can avoid using a "yes/no" request/response policy server and instead have a policy server syndicate global policy that Web Service security handlers in the enterprise enforce, there can now be centralized access control enforcement. This provides the benefit of total control that the decentralized model was lacking and eliminates the availability threat, the enterprise bottleneck, and the performance concerns that were inherent in the centralized model.

Allowing Web Services to express their own "local" access control policies removes the potential management burden of having to dictate policy for the entire enterprise. The trick, however, will be conflict resolution between syndicated global policy and local policy, since global policy must always trump local policy.

Centralized auditing can be handled by using network logging and a central auditing server, where all access control events from local Web Service handlers are sent to a central auditing or Web Service management server.

What this model lacks, however, is the benefit of information hiding that's present in a completely centralized security policy model. As we addressed before, the yes/no policy server abstracts the reason that decisions are made, which can be a very good benefit in situations where the security policies themselves are extremely sensitive. This is very uncommon, and if this requirement exists, it may only pertain to some components in your enterprise. If this is the case, you can complement the solution I'm describing with a centralized policy server used only when absolutely necessary.

Conclusion
This article has provided an overview of some of the issues that organizations face regarding SOA access control policy management and enforcement, looking at the benefits and pitfalls of two common methodologies. We presented a best-practice approach that can be used in your enterprise. As with any security solution, it's important to focus on both your short-term, long-term, and even potential security requirements to plan the most scalable approach.