More and more businesses are seeking to exploit their enterprise integration technology investment by extending it to include external business partners.
But attempting to integrate with another business’s systems inevitably raises security concerns and presents identification and authorisation challenges.
Regardless of the approach a business has taken internally to enterprise application integration (EAI), the increasing availability of open, secure interconnection standards and products which support them, provides the tools needed to meet these challenges.
Increasingly, businesses are turning to EAI vendors and/or bespoke web services development to integrate their business applications and address business process ‘hot spots’.
Phases
The introduction of web services technology typically happens in three phases:
- Small-scale, toe-in-the-water bespoke inhouse development.
- Larger-scale integration of existing systems using middleware.
- Full-scale deployment of all the pieces of the EAI jigsaw.
The initial phase introduces a new development using either J2EE or .NET. This development usually scratches some compelling business itch, but rarely integrates existing systems.
The next phase integrates one or more existing systems, usually by investing in messaging middleware connection infrastructures.
Full-scale deployment adds all the bells and whistles offered by one or more vendors’ enterprise application integration offerings, delivering a complete integration solution.
A full solution will typically include a corporate directory to centralise user and authorisation management, an identity server for management and provision of authentication services, middleware connections to integrate existing business systems, and perhaps a business process engine to allow users to explicitly manage and control the now-integrated business.
Many vendors are offering integrated solutions with such end-to-end coverage. Examples include Sun ONE, IBM WebSphere, the Sybase BPI suite and Oracle Workflow.
Some businesses choose to construct their complete solution from elements supplied by different vendors, taking advantage of open standards to achieve the interoperability they want.
Others are attracted to the idea that the vendor will have already solved any potential integration teething troubles and will supply the solution pre-configured, warranted to ‘just work’.
Each of the three phases will have a different impact on the deploying business.
Every part of the solution that is bought in, lessens the effort that will be expended on a custom solution to a commodity problem.
Choices
The most fitting approach for any given business depends on the extent and nature of the process hot spots being addressed, the existing infrastructure portfolio, the range and type of systems being targeted, the level of application and process integration sought and, last but not least, the depth of their pockets!
But whatever investment approach a business takes for its EAI infrastructure, at some point during the development and deployment it will face a requirement to integrate with its own external business partners.
The challenges of security and manageability presented by external integration create a problem that has similarities to the classic late 90s ‘single sign-on’ problem.
During the 90s, the single sign-on issue was mostly confined to the internal systems under the direct control of a business. Solving it meant users could access all their required systems using only a single login and password.
Achieving this within the comfortable security of the internal corporate network was challenge enough in the early days of LDAP and Active Directory.
In the current climate, the needs of e-business have driven the need to interoperate with external business partners’ systems. This only increases the complexity of the integration problem.
Regardless of whether this external integration is being delivered over the internet or via secure extranets, the difficulties of defining the structure of authentication and authorisation information and then sharing it with external partners remain the same.
Businesses need to be able to reliably and securely validate users of their integrated systems, and define what those users can and cannot do.
They need to be able to manage their users and permissions across the systems they share with their business partners.
Rather than repeat the definition, negotiation and agreement process with each new partner they wish to communicate with, businesses are increasingly seeking solutions based on open standards.
This need for secure interoperation capability has not gone unnoticed in the software industry. Many initiatives are well underway to attempt to address the burgeoning business requirements. The majority of these initiatives are based on XML.
The platform-neutral nature of XML has led to its rapid and unchallenged adoption as the natural vehicle for information exchange solutions in many domains.
Businesses seeking open standards solutions to their authentication and authorisation challenges are closely tracking a variety of emerging XML-based standards such as the:
- Security Assertion Markup Language (SAML).
- eXtended Access Control Markup Language (XACML).
- Web Services Security specification (WS-Security).
- The Federated Network Identity work of the Liberty Alliance.
These emerging open standards enable companies to meet the challenges of secure interoperation with external businesses. They are of use to companies in two ways: some will find them a basis for the development of bespoke solutions; others will use them as requirements in the package selection process when buying and deploying conforming products from vendors.
Milestones
Establishing an operational corporate directory is a key pillar on which successful EAI architectures will be built. The next key milestone will be defining a strategy to secure and integrate that directory with external partners.
Expect to see Active Directory rollouts revisited, and renewed interest in LDAP products and open standards, as businesses seek to gain control of what can be done and seen by whom within their corporate hierarchies.
Packages and tools that can interoperate seamlessly with Active Directory and/or LDAP will be top of the EAI implementation shopping list. Those that support open standards to simplify secure external integration will be even more sought-after.
Definitions
SAML is a standardised framework for exchanging authentication and authorisation information between businesses. Using SAML, compliant access-management and security systems from different vendors can interoperate.
SAML doesn’t actually perform any authentication or authorisation, but instead provides a common way to communicate the knowledge that these events have happened across heterogeneous systems. It provides a way to exchange validated information about identity.
XACML is a language for describing access control policy. It allows an organisation to express, test and share rights in an open, commonly understood manner.
XACML is a request/response language, which allows questions about rights to be asked and answers received. SAML can be thought of as providing a way to exchange information about who someone is; correspondingly, XACML can be considered a means of sharing of what they are allowed to do.
The Web Services Security specification defines a standard way to enhance SOAP messages to add security. SOAP (the Simple Object Access Protocol) is the de facto standard for web service messaging. WS-Security provides a common way to combine SAML assertions with SOAP messages.
The Liberty Alliance is a consortium of more than 160 members (the current management board members being American Express, AOL, Ericsson, Fidelity Investments, France Telecom, GM, HP, Nokia, Novell, NTT DoCoMo, Sony, Sun, VeriSign and Vodafone). Its aim is to promote the use of open standards for federated identity management and services.
The alliance has released a set of specifications defining mechanisms for creating and deploying federated identity networks across businesses, referred to as the Phase 1 specifications.
Its Phase 2 specifications add several new elements to the architecture, including affiliation, anonymity, permissions-based attribute sharing and identity discovery services.
The Phase 2 specifications are currently released at draft status. Products based on the Liberty specifications have started to come to market.
