Pragmatism Pays with Security
LibGo has agents in stores, consumers online, and call center service representatives. The agents are responsible for bookings; managers must be able to obtain information on bookings and override policies. Given that the composite application incorporates business logic in NGTS, many ERP modules, and partner systems, the main challenge was to install a common access, authentication, and authorization framework across the applications that would enforce security and also enable auditing and logging (for compliance reasons).

To achieve this, LibGo used the HR model in Oracle e-Business Suite HRMS, along with Oracle Application Server Single Sign-On (SSO) and Oracle's Internet Directory (OID) LDAP store. User, resources, and entitlements from Oracle HR are populated into the OID store, which has application-specific objects. Every application and role has a set of entitlements; for example, agents may be allowed to accept partial payment for over-the-phone bookings, but customers who use the Web interface cannot do the same. All applications are then registered with SSO to provide SSO and role-based authentication for all applications via JAAS (the Java package that lets applications authenticate and enforce access controls upon users). LibGo uses Oracle Application Server Portal and SSO to consolidate services and bind them into a user interface, and to provide a common security and personalization framework for enabling access to packaged applications, business intelligence and reporting applications, and composite applications in NGTS.

To secure communications between LibGo and external partners, we took a pragmatic approach of using secure frame relay lines with VPN as a backup solution. Such Web-based security approaches are a little heavy-handed because they often secure the entire wire protocol rather than just the SOAP message that is sent over the protocol. Further, for many message-based integration projects, several intermediary steps are necessary before messages arrive at their target endpoint, and transport-level security leaves the messages unsecured at each intermediary checkpoint.

To achieve a finer level of control and to avoid the intermediary security issues, LibGo is moving from today's existing transport-level security to message-level security. WS-Security defines a mechanism for adding three levels of message-level security to SOAP messages:

• Authentication Tokens: WS-Security authentication tokens let clients send, in a standardized fashion, username and password or X.509 certificates for authentication within the SOAP message headers
• XML Encryption: WS-Security's use of the W3C's XML Encryption standard lets the SOAP message body, or portions of it, be encrypted to ensure message confidentiality
• XML Digital Signatures: WS-Security's use of the W3C's XML Digital Signature standard lets SOAP messages be digitally signed to ensure message integrity. Typically, the signature is a computed value based on the content of the message itself: if the message is altered en route, the digital signature becomes invalid.

Conclusion
Building an enterprise-wide SOA is challenging. As more capabilities move into standards and into the middleware stacks of the vendors, however, the task should become easier. For example, when LibGo embarked on this project, Web services orchestration solutions were in their infancy. Now, it is possible to get high-performance, manageability, auditability, exception management, and a framework for building compensating transactions from BPEL Process Manager. In building out our SOA, we had a clear view of the evolution of standards and how capabilities around security and transaction management would work their way into products. When building your SOA, make sure you have this view - so you don't end up producing tomorrow's legacy systems.

• Building a Modern SOA: Examining Offshoring All Over Again