Chapter NINETEEN. ESA Security

One of the more daunting challenges facing enterprise architects is reinventing the security model for business processes and the composite applications that support them. Traditionally, securing monolithic applications has simply been a matter of securing who had access to them, which meant that the user interface (UI) was the gateway and the natural point at which to guarantee the user's identity and permissions. Security inside the application itself was left to the vendor.

But in the world of ESA, service becomes the platform's problem, and defining access to services and the structure built on top of them is a more delicate, complex matter. Authentication at the UI is merely the first step; after that, the user's identity and role within the landscape must flow through composite applications, passed from service to service and checked by each, and the overall security of the process from one end to the other must be ensured. Further complicating matters is the fact that these services might comprise business processes which touch any number of external systems, including, perhaps, the host company's customers and/or partners, which raises another raft of issues.

An entirely new set of concerns, meanwhile, revolves around the sudden exposure of critical business processes to assault by malicious parties residing on the Web. Corporate firewalls may have eliminated most of the potential avenues for attack by hackers, corporate espionage, or what-have-you, but the new architecture often means that the overwhelming majority of SOAP messages now move through the still-open HTTP port, vastly diminishing firewalls' ability to screen traffic. In the age of enterprise services, corporations cannot afford to bury applications deep in their systems, which limits their effectiveness; nor can they afford not to see what's hiding inside every packet arriving at services, which requires new strategies and new security capabilities.