News Stay informed about the latest enterprise technology news and product updates.

SOA governance, security concerns drive XACML interop

The policy requirements of service-oriented architecture (SOA) require major vendors, including IBM, Oracle and BEA Systems Inc. to demonstrate XACML interoperability.

Leading vendors in the service-oriented architecture (SOA) space are working to demonstrate interoperability with Extensible Access Control Markup Language (XACML) 2.0 for their Web services software products.

The policy requirements of SOA are driving XACML, a two-year-old OASIS standard, into the forefront of security and governance considerations for vendors and their customers, said Hal Lockhart, senior engineering technologist principal for BEA Systems Inc. and co-chair of the OASIS XACML technical committee. Lockhart along with Rich Levinson, principal member of technical staff for identity management/standards architecture at Oracle Corp., are working with the other vendors to resolve XACML interoperability issues. Tuesday they previewed a XACML interoperability demonstration planned for Burton Group Inc.'s Catalyst Conference later this month.

Since it's going to be used by other services in different ways, the policy requirement is definitely becoming more complex than traditional environments.
Hal Lockhart
Co-ChairOASIS XACML Technical Committee

The analyst firm is providing a neutral forum for competing vendors to demonstrate XACML interoperability, explained Gerry Gebel, vice president and service director at Burton, who hosted the teleconference preview. Burton also will provide a forum for Microsoft and the Liberty Alliance to begin an interoperability effort for their competing user centric identity management technologies.

"It's great to see competitors working toward common goals," Gebel said, explaining that Burton believes interoperability is the key to achieving maturity for these Web technologies and standards.

XACML probably has not been the first standard to come to mind in discussions of SOA, but Lockhart said SOA and the rise of software as a service (SaaS) are major factors in driving the interoperability demonstration that will include BEA, Oracle, IBM and Red Hat Inc.

"There are three recent trends which all are driving the need for fine-grain access control," he explained. "SOA is one of them because instead of constructing your system from a large monolithic piece you have a lot of independent services and each service is going to need to enforce its own access control. Since it's going to be used by other services in different ways, the policy requirement is definitely becoming more complex than traditional environments."

The other two trends are the increasing number of Web services being exchanged beyond the firewall with business partners and customers and the rise of SaaS, Lockhart said.

"I think you are going to see with software as a service there's a need for fine grain access control because you are going to be integrating components that are in your organizations with components provided by one or more third parties," he said. "Fine grain access control will take into account business relationship contracts."

Fine grained access control is what differentiates XACML from two complimentary standards for Web services interaction, Security Assertion Markup Language (SAML) and WS-Security Policy, Lockhart explained when questioned about how the three standards are related.

Asked about the difference between XACML and WS-Security Policy, he replied, "If you look at WS-Security Policy it's primary purpose is to allow a service to publish or make available what requirements there are to access it. Whereas in XACML, the purpose is to actually check whether or not a given access should be allowed. Those may sound similar, but in fact the difference in intent leads to differences in how they are designed. WS-Security Policy provides much less detail and is designed in a form so that it can be matched. For instance, a requestor can match what it's capable of doing with what's being advertised by the service. Those would be complimentary purposes."

Demands for even greater security and privacy may lead to an even closer relationship between XACML and WS-Security Policy in the future, Lockhart predicted.

"There are some people who for privacy reasons are interested in adding finer detail to the policy they advertise," he said. "So we're working for XACML 3.0 on a profile that would let you attach an XACML policy to a WS-Security Policy to provide more detail around, for instance, privacy considerations.

Asked how XACML and SAML assertions relate to each other, Lockhart answered, "With XACML the intention is to make use of any kind of information for making a decision. SAML is a very good source of providing information about users or, in technical terms, subjects. So for example, SAML has an assertion that tells that a certain party logged in at a certain time using a certain method. Also, SAML has a different assertion that lets you say that a certain party has certain attributes. All of that information could be used as input to an XACML policy decision."

The interop, which will use hypothetical financial services stock trading applications, will focus specifically on the capabilities of XACML and how the participating vendors' products can work together in a heterogeneous environment, said Oracle's Levinson.

For more information
OASIS advances security standards

James Bryce Clark, SOA standards move past plumbing

"We will demonstrate the policies created by one product can be consumed by another product," he explained. "The first purpose of the interop is to demonstrate XACML's primary functional capabilities, which is to enable the abstraction of authorization logic from applications, so you can do your authorizations from central locations. The value of the central location from a business perspective it that at the policy decision point you can specify all of your critical business rules in a common, seamless manner. It provides a focal point for the enterprise for defining the enterprise policies."

Levinson said vendor interoperability has been achieved through following the common policy specification language specified in the OASIS standard and the use of common application-specific vocabulary, which the vendors have now agreed upon.

The interoperability demonstration is scheduled for the evening of June 28 at the Burton conference in San Francisco.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.