What is the real issue in web services security?

	express delivery
	• print  • comment
	The objective of loosely coupled integration is often completely lost when security integration is added: Linking separate applications often means linking separate user access security processes It's best to manage user identity and access policies outside individual applications But centralized security solutions quickly run out of steam Federated identity across multiple security domains bring greater flexibility Standards such as SAML play an essential role but many remain incomplete This article was first published in the April issue of the Loosely Coupled monthly digest.
	Glossary terms: WS-Security, SAML, Liberty Alliance, digital identity, loose coupling, lookup tool Sponsored links: your text link here

When techies talk about it, they're typically talking about intruders intercepting trusted XML messages and substituting malicious code. Business people, who take this kind of wire-level security for granted, are more concerned about tracking the identities and activities of users who log on legitimately: "Threats come internally within an organization — from within your secure environment," says Christopher Crowhurst, VP enterprise architecture at computer-based assessment provider Thomson Prometric.

Of course technologists have a duty to master the fine detail of securing the web services infrastructure. But it's no good focussing all your efforts on guarding against XML hackers, when failing to get to grips with the complexities of access and identity management in a web services project could expose sensitive data to the wrong users.

"Questions of identity are perhaps more sophisticated than the security of XML itself," says Mark O'Neill, CTO of web services security vendor Vordel. "If your web service is being accessed through a portal, you have to have a way of tying the web service to the user. The issue is that you have someone authenticating in one place and using a service that's somewhere else." The two processes may be independently secure, but maintaining security when the applications are linked together means integrating their separate mechanisms for authenticating users and controlling access rights.

Across the security divide

Since most web services integration projects set out to link hitherto separate application silos, it's all too common that they also span hitherto separate security domains. This can often mean that the original objective of achieving a more flexible, loosely-coupled integration is compromised or even completely lost when the security integration is added.

A common quick-fix is to embed security into the web services application, even to the extent of setting up separate user names and passwords for accessing the services. But as web services proliferate across different application stacks within the organization, that approach quickly runs out of steam. "We encourage people not to mix their security policy with their business logic," says Vordel's O'Neill.

Reconfiguring every single instance each time there's a change to the security policy rapidly becomes an unmanageable proposition, and on some platforms it is not even an option, he explains. "People will have a mixture of different web services platforms, and they'll have products that have a SOAP stack embedded in them — for example SAP NetWeaver. You won't necessarily have the opportunity to go in and alter the application code and change the security."

Most web services vendors agree that the only viable solution in the long run is to set up and manage user identities and access policies as a separate dedicated resource, and then implement the web services infrastructure so that it enforces those security rules.

Many organizations already have a centralized identity and access management system — but that doesn't necessarily mean they're home and dry. “The current methods for achieving [access management] make for a tightly coupled system for co-ordinating your security," warns Kerry Champion, founder and chief architect of web services security vendor Westbridge Technology, because they're rarely up to date with web services standards.

And even if an enterprise does successfully standardize on a single identity and access management infrastructure internally, it only gains a temporary reprieve from security integration challenges; it will have no choice but to support heterogeneity once it begins deploying web services in a B2B environment.

The alternative is to adopt a loosely coupled approach to identity management that acknowledges the existence of multiple security domains, and which is able to match each user to the appropriate security policies for each domain. In other words, approach security itself as a services integration challenge, setting up mechanisms for exchanging authentication and authorization data between systems. This involves implementing standards and technologies for sharing access to user profiles, to security policies and matching profiles and interpreting policies between systems.

None of this is easy, as Prometric's Crowhurst will tell you, especially while many of the key standards are still evolving. But he's clear about the core foundation: "The issue goes purely to identity," he says. "You're talking about federated identity management and how you do that."

As the world's leading provider of computer-based testing services, Prometric (which uses software from Actional to manage its web services infrastructure) faces an identity management challenge that's bigger than most. It has a user base of many thousands of trainee professionals and a client base of several hundred examining bodies, ranging from the likes of Oracle and Sun Microsystems to the American Institute of Certified Public Accountants. Although it is offering a specialized service rather than a conventional product, the principles are no different from any manufacturer or retailer that works with partners to serve a customer base, and serves to illustrate the complexity of federated identity management.

"We call it customer mastery," says Crowhurst. The system must recognize each individual user each time he or she logs on, and then pass the relevant credentials through to each service the user attempts to access. In a federated identity system, those credentials will probably vary depending on the context — for example, the user known to Prometric as Christopher Crowhurst may have registered with Oracle as Mr Chris Crowhurst. The system must be able to match both variants of the name to the same holistic identity profile, while still using the right variant and its associated credentials in each context. "If we don't have the ability to maintain identity holistically then we just end up duplicating information," Crowhurst explains.

One into many does go

The essence of federated identity management is this ability to maintain a single holistic profile for each user within the internal infrastructure, while supporting the multiple identities and matching credentials associated with that individual when linking to the outside world.

When using web services, the next challenge comes when an authenticated user wants to access a specific resource. There needs to be a way of securely passing the appropriate credentials from the access management system through to the requested web service. Like most early adopters of web services, Prometric's chosen mechanism is based on the established OASIS standard for single sign-on, SAML (Security Assertion Markup Language). "It seems to me SAML is the only real path for doing that at the moment," says Crowhurst. O'Neill agrees: "You can get a lot of mileage from SAML." Most of Vordel's customers today use SAML alongside credential mapping, which authenticates partner identities to the corresponding local identities set up for partner access.

Other technologies are also needed, and there's a real urgency to see the associated specifications officially endorsed as standards. Crowhurst welcomes the imminent approval of WS-Security, and in particular two of its components related to encrypting messages and attaching digital signatures: "We definitely need WS-Encryption and WS-Signatures approved so that we can have vendors implement them." Prometric is already using these technologies but warily. "I'm kind of feeling nervous in that space, but we have no option but to use them," he says.

Firing at a moving target

Vordel's customers are similarly wary. "We can get a lot of cynicism out there about specifications — people don't want to base their security on a moving target," says O'Neill. "We're certainly very excited about WS-Trust and WS-Policy, but we're hesitant about recommending them to customers because they're not standards yet."

For example, plans for WS-Federation in a future iteration of the OASIS security specs will overlap proposals from the Liberty Alliance, which has clouded the roadmap for SAML going forward. Other proposals are more welcome, such as WS-Policy, which specifies how a service signals the type of security it requires. Before it arrived, says O'Neill, "there had been no way of alerting that to the client — you could be blocking messages and the client wouldn't know why." And plans for WS-SecureConversation will make it quicker and simpler to send messages securely in batches.

"These things are useful pieces in making the whole thing work," says O'Neill. But they're supplementary to the core requirement to securely authenticate user identity and access rights over different trust domains. That depends on building links between security systems, for which federated identity standards will be crucial. "You can't integrate without identity and that's been fundamentally mishandled by application developers for years," Crowhurst concludes. "The cost of doing it retrospectively is vast."

Thanks to the emergence of standards that allow federated identity management, Crowhurst believes we've got a chance to put that right now.

More on this topic