I'm sure I'm like many of you in this respect: I got into engineering because I love the idea of being able to address complex problems with a combination of my talent, my friends' talent, and the tools that I can come up with to make our work as easy as possible (work smart not hard!). It is this approach that has guided me in my work as an application and technical architect. I come to work every day looking for that "wow" feeling that comes when I realize that another problem that seemed intractable has been solved. But in the pantheon of hard problems that beset projects I work on, a disturbing antipattern has emerged regarding application security design.

It goes like this: the business declares a requirement for zero tolerance for security flaws (it is a catastrophic problem for one user to see another user's account, or HIPAA requires that no one see some data in a user's profile except the user or her doctor, and so on)...then the architecture team looks at the tools on hand and decides that they don't pass muster...then the architecture team searches high and low for some tool or framework that will do the trick...they don't find anything and decide to construct it for themselves thus turning over to QA a huge burden of making sure that the result always works. And the worst part is that the maintenance cycle is merciless on home-brew security systems since they have to evolve - new roles and constraints are often added on a regular basis, meaning that application developers might need to change code if they did their job without enough foresight, and QA needs to retest the system in any event.

I'm happy to say that I recently had that "wow" feeling again with regard to application security after doing Web services security architecture for a few months. I'm going out on a limb and predicting that Web services and WS-Security standards will lead to a paradigm shift in the way that applications are secured.

Application Security Infrastructure - Separating Policy from Code
Security policy and enforcement must be separated. Architects have long recognized this as a fundamental design tenet for applications. The last paradigm shift in application security architecture was the emergence of tools and frameworks that allowed user access management infrastructures to be deployed as a service that is shared between applications. Identity and access management solutions emerged when the Web got popular as a means to implement Web resource access policy and single sign-on (SSO). These systems were generally quite successful in managing user access to Web sites, and even delivered plug-ins for application servers with which we were able to do static access control list (ACL)-type security against things like JNDI locations and access to EJB methods. They never delivered a means to do fine-grained entitlements or data security. We looked to other means for that. We still wanted an infrastructure approach to the problem and so many of us wrote our own security providers for app servers.

Managing User Identities - Everyone Wants to Control Their Own Destiny
Just as hard to get your arms around if you're an app architect is identity management. Most applications have user self-service functionality. Some have a large number of functions that users can manage. Everything from self-registration to password resets, and personalization settings are managed by the application itself, or so it seems to the user. Same thing goes for delegated administration. If I am a financial advisor, for example, I may well be able to manage my clients' accounts and even grant them access to view their accounts on the Web. I likely will not be able to view the accounts of a colleague's clients. Behind the scenes is a part of the application that manages the identity store - usually an LDAP store. The same access management tools that implement Web access policy often provide a Web app of their own for this purpose, for a jaw-dropping additional license fee. And so we architects have been dealing with these identity and access management (I&AM) tools for the last few years, biding our time for more fine-grained security functions that could look at a parameter or two (data security).

There is a (Much) Better Way
I am glad to say that there is a much better way now to do fine-grained application security. The premise of this article is that Web services security policy can and will supplant existing app security policy and in doing so will greatly limit the difficulty and expense of securing applications and managing user identities. I am suggesting that for the first time we will be able to include fine-grained policy and data security in the security infrastructure itself instead of in application code. And we will be able to expose "raw" SOAP interfaces to the I&AM system and have delegated administration and user self-service schemes encoded as WS-security policy. As you must have surmised by now, to make use of this scheme applications must leverage Web services for interaction with the business service tier. I don't see this as a caveat, I see it as desirable. And so do the clients I currently work with.

Security Standards We Need - A Quick Review
Like all other things Web services, standards are the heart and soul of Web services security. A quick review of the standards upon which we rely is in order. And it all starts with the aptly named WS-Security standard, which is the granddaddy of them all, having been around in some form for two years. WS-Security is all about bringing integrity and confidentiality to SOAP messages, and is also concerned with conveying the identity of the requestor on whose behalf the message is sent. The standards relied upon are XML-Signature, XML-Encryption, and SAML (for which a SOAP token profile is provided). SAML (Security Assertion Markup Language) details both a grammar for representing user identities via tokens and a protocol for gathering user attributes and authorization decisions. XACML is a grammar that details security access policy and a high-level protocol for access requests and responses. The XACML protocol is given life via a SAML profile in the SAML 2.0 draft - we will put this to good use shortly.

The Web Services Policy Ecosystem
Figure 1 illustrates the Web services policy ecosystem as specified in SAML 2.0 and the SAML profile for XACML. Policy is enforced at the policy enforcement point (PEP) and calculated at the policy decision point (PDP) - we still have the separation of enforcement from decisioning that we insist upon. The difference is that we will do all of the enforcement in the infrastructure in this architecture. In doing so, we may need to gather more context information, both at the level of the PEP and the PDP. This is accomplished with the policy information point (PIP). In the XACML policy model, attributes are gathered into one of four categories of the request context: Subject, Resource, Action, and Environment. The PDP will make an access decision based on the attributes in these categories, with respect to the policy for the targets in the request context. The policy administration point (PAP) supplies the policies to the PDP. The interaction between the PDP and the PAP is very interesting and I would encourage you to check out the XACML standard at OASIS. Understand that there are no real XACML tools on the market yet, though they will soon appear - we actually have PEPs now but are still waiting for XACML PDPs and XACML policy stores and associated administration tools. Instead, let's focus on what we currently have to implement the policy ecosystem.

Tools to Enforce Security Policy in the Infrastructure
Since I can't just overlay each of the policy ecosystem bubbles in Figure 1 with some tool function just yet, we will have to improvise. Luckily, there are some very good tools in this space already, which makes this task bearable. In fact, without these tools it wouldn't be possible at this time to implement the premise of this article. Central among the tools we leverage is the XML security gateway, otherwise known as an XML firewall. There are many of these tools on the market now, mostly from startups, and they are ready for prime time. The best of them do everything from content routing to XML acceleration, but most importantly security policy enforcement. They also offer configurable logging. And the ability to log access decisions and request content is very powerful, as we will see in our use case.

The best of breed, in my opinion, is the XS40 from DataPower. This device is incredibly fast and incredibly flexible at the same time. It is equally adept at running the entire show with everything from PKI management to policy setup and enforcement as it is at deferring everything but the actual enforcement to other systems in your enterprise. And it screams. It is hard to stack enough validation, enforcement, and cryptography functions on it to slow it down below wire speed...at transaction throughputs that would run the economy of a small country. And that's just one box. Load up a cluster of them and the sky's the limit. The main take-away for our purposes is that we will do our message-level security functions, XML attack countermeasures, logging, and our policy enforcement all at the same time and not worry for a second about performance.

The second tool that we will rely upon is the Web services management fabric. Web services fabric tools allow administrators to manage every aspect of a Web services endpoint, from global security constraints a la WS-Policy (like whether messages must be encrypted or signed), service levels and provisioning, and eventually fine-grained policy via XACML. WS fabric monitors service latency and enforces policy via a network of policy enforcement points that are spread throughout the enterprise. This control network is a very powerful distributed management system and will surely assume more functions over time, including the ability to enforce fine-grained policy (I hope). The best tool in this space is Blue Titan Network Director. I am impressed with the maturity of the Blue Titan fabric and with it's ease of use.

To get farther using Web services and Web services security standards to build an application security infrastructure you need trust and federation. These are beyond the scope of this article and still evolving. What I will define is what I call "poor man's trust," which will support federation in our infrastructure. All that is required is an agreement to exchange SAML (version 1.1 for now, but 2.0 in 2005) identity and attribute assertions, along with the exchange of certificates and attribute requirements for relevant applications.

We map identities from the trust domain to a single entity in our user store, which represents the trust domain itself. We add attributes to further describe the trust domain. These attributes will be added to those sent by the asserting application in the trusted partner's enterprise, in keeping with our policy ecosystem. This is actually a very reasonable trust model if you just have a few trust domains. Beyond a few you'll need the full-on trust stack - and you can expect that to get tool support in the next year. As for current federation tools I think RSA's Federated Identity Manager (FIM) leads the pack. It currently supports SAML 1.1 and provides the attribute query service we need to make our simple trust model work.

A Real-World Use Case
We have enough architecture and tools to focus on a real use case. In this use case we have a remote finance department that has surfaced a portal to allow buyers to approve invoices in accounts payable against a centralized accounting system. Picture a global company with accounting offices in each country but with centralized accounting systems - very realistic. Trust has been established in which we have set up an entry in our identity store to represent the remote finance department and receive their digital certificate such that we can verify the SAML assertions they send. Figure 2 illustrates this setup and overlays the policy ecosystem elements onto the tools we would like to leverage (note that I say "like" - this is a future-state view of the tool functions that will shortly be brought into the present...).

All that remains is to specify the security policy we would like to enforce. To make things as realistic as possible, let's assume that the remote trust domain sends an attribute that defines the amount of an invoice that can be approved by the buyer without further approvals. This means we need a policy that compares a subject attribute (the approval limit for the buyer) with an XPath expression to find the amount in the invoice document. Also assume that the buyer is required to have authenticated via hard token, and is required to have come in from the trusted domain "remote.fincence.com". Listing 1 is the XACML policy expression that defines this policy against a fictitious Web service endpoint. This example is given as a point of reference for how policy is expressed with XACML. Listing 1 takes some liberties with the resource and action targets (like ignoring the WSPL binding for Web services!). Listing 2 is the request sent to the PDP by the PEP for an authorization decision for a buyer from the remote site with an invoice approval limit of $100K. For the sake of argument, assume that there is an invoice attached with an amount of $90K - authorization = PERMIT!

Now for the reality check. It turns out that currently the fabric tools on the market do not wrap all of the PAP and PDP functions...one day I hope and assume they will. Therefore, we need to define the policy in two places - in the XML firewall IDE and in the Web services fabric IDE. Each enforces policy around their area of focus. The XML firewall does the bulk of the enforcement including policy around encryption and validation of digital signatures. In this case, we also leverage it to enforce our application security policy. If the invoice amount is $101K and the buyer's approval limit is $100K, the request will be denied. The fabric PEPs are distributed throughout the application deployment space and are used to enforce the same policies that the XML firewall enforces, but in circumstances where the XML firewall can't - such as if it was bypassed by an internal request conduit. In both cases, all policy enforcement actions, including request content and policy enforced can be logged in a configurable manner. This also affords us the opportunity to create a type of nonrepudiation log that is very important in today's regulatory climate, e.g., Sarbanes-Oxley. The DataPower XS40 can be configured to log certain requests (based on almost any imaginable rules) to a separate log that the firewall will then sign every so often. Then when the attorney general walks into the office and demands to see a validated total of all invoices paid against a certain account, you're good to go. Figure 3 shows the policy ecosystem overlays as they exist today with today's tools.

Identity Management Redux
Guess what happens to identity management in this scheme - those pesky policies that we spent so much time and money enforcing are now just additional entries in our PAP! Go ahead and expose those LDAP identity management functions as raw Web services (that's only a few days work) and let the policy ecosystem do the rest. Your application's users will be able to leverage those exposed services via the application portal and the security infrastructure will make sure that your policy desires are followed to the end brace. You can then just tell the portal team where the services are and ask them what policy to enforce and that's that!

Conclusion, and the Road Ahead
I hope I have conveyed to you the great advantage of bringing application security policy functions into the infrastructure. We saw a bit about the policy enforcement standards and protocols that we will enjoy with SAML2.0/XACML 2.0 and looked at the tools to use right now. What's coming in the WS-Security space is compelling indeed. You won't need much more than what we have gone over to do everything from applying digital rights licenses based on policy rights to all forms of media that leave as SOAP attachments, to federating instant messaging identities while applying corporate security policy. And the scary part is that even though we are focused on SOAP, these tools can talk other protocols and even bridge protocols. Think of applying XACML policy to your MQ environment and even translating it to SOAP/HTTP, and at gigabit rates! All I can say is "wow".

• Figure 1
• Figure 2
• Figure 3
• Source Code