Featured White Papers

• Why choose an Open Source BPM?
• 10 FAQs on Business Process Management
• Best Practices for Getting Started with BPM
• Free Your Devs From The Pain Of Java Redeploys
• Increase Velocity 40% by Using JRebel
• What Developers Want: The End of Application Redeploys
• Developer Productivity Report: Java Tools, Tech, Devs, and Data
• Coding with JRebel: Java Forever Changed
• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• APIs for Java Programmers: Manage & Convert DOC, XLS, PPT, PDF & More

• Instantly Preview Java Code Changes: JRebel.com

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Secure your SOA

Enterprise-grade SOAs require a plan for addressing diverse security needs

By Ash Parikh, Anthony Sangha and Murty Gurajada, JavaWorld.com, 04/10/06

Page 6 of 6

XACML can base its decisions on a resource's properties, including its content, or on environmental factors, such as date, time, or location. It may also take into account properties of the parties associated with the request, such as role or group membership. This might include not only the party making the request, but also the party receiving the data or intermediaries to the request.

As shown in Figure 2, a typical usage scenario of XACML is where a subject wants to take some action on a particular resource such as a filesystem or a Web server. That subject submits its query to the entity to protect the resource. This entity is called PEP (policy enforcement point). The PEP forms a request, using the XACML request language. The PEP then sends this request to a policy decision point (PDP), which examines the request, retrieves policies (written in the XACML policy language) applicable to this request, and determines whether access should be granted according to the XACML rules for evaluating policies. That answer (expressed in the XACML response language) returns to the PEP, which can then allow or deny access to the requester.

SOA security enabled by XQuery and XML databases

Security standards and secure documents are described using XML and the various XML markup languages discussed in this article. An XDMS is an ideal mechanism to persist and query both security policy documents and secure messages in an SOA. As mentioned earlier, XQuery can be used to extract information from XML documents. XQuery is basically a functional language that uses expressions as the central component to assemble queries. Each query can be described as a set of expressions, which may be nested. This main feature makes XQuery a flexible and well-rounded approach for manipulating XML data.

To effectively access or store XML documents, one needs an XDMS. An XDMS that supports XQuery can enable the retrieval of information from the XML security documents quickly and easily. XML databases have matured and readily provide XML content search and storage.

For example, an XDMS can maintain different versions of security policy documents, providing an audit trail for policy changes. Furthermore, XML security messages and requests can also be persisted, providing an audit trail of all security transactions in an SOA.

SOA security enabled by federated identity management

According to Jason Rouault and John Worral, authors of "Federated Identity Management Addresses E-Business Challenges":

"a single organization cannot effectively manage or control an e-business initiative from beginning to end, especially when multiple partners are involved. Even within the enterprise, different business units often manage distinct sets of users and resources. That's why organizations are turning to federated identity management to address their e-business challenges."

Applying these ideas to our typical supply-chain use-case that involves many disparate applications collaborating with each other through Web services, we can see that without federated identity management, total chaos caused by unauthorized and untrusted access to the underlying SOA-enabled business processes would reign—thus defeating the very purpose of collaboration.

Federated identity standards such as SAML and alliances such as the Liberty Alliance form a wrapper around disparate systems and their respective security infrastructures, and enable them to interoperate, forming what is called a circle of trust. This is the first step towards developing business relationships across trading partners and business applications.

SOA governance

As SOA implementations scale and become more mature, governance becomes imperative to their success. SOA governance is the process of defining and enforcing organizational policies and standards. These policies are geared towards the business requirements of managing liabilities and dependencies, ensuring continuity of business operations and reducing costs. They also benefit the IT departments by defining controls for service proliferation within the enterprise, incorporating evolving standards and promoting interoperability.

Today, most organizations already have policies in place for all of the above. However, these may either be manually enforced or in disparate places across departments and applications. We need federated information and policy management as XML metadata that resides with the SOA artifacts to facilitate automatic enforcement, without manual intervention. This is the only way to guarantee fast, reliable, and consistent application of SOA policies within and across organizations.

Federated information management needs features for organizations to share and link information securely. Enterprises may need to maintain their own data repositories as well as a unified view of data that must be exchanged between trading partners. Federated policy management includes publishing, managing, discovering, and governing organizational policies. When multiple partners interact with each other, these policies must be linked and composed across enterprises.

The goal of SOA governance is to create an infrastructure that is robust and secure. This is not possible if you only provide policy enforcement at an XML registry level. The bulk of SOA artifacts created by your organization is in the documents you exchange with your trading partners. Hence, you must have fine-grained governance over this data to truly secure your enterprise. For this, you need an SOA repository, not just an XML registry.

An SOA repository should be the central point for governance of all your SOA artifacts. But imagine the vast amounts of XML SOA metadata that needs to be persisted with the SOA data. Only a fast and scalable SOA repository that provides querying and management of enterprise data would work for Federated Information and Policy Management. The most optimal way to achieve this is if the repository is powered by a native XDMS with XQuery to provide both speed as well as scalability to realize effective SOA governance.

As we noted earlier, XQuery is a flexible and powerful language for XML data retrieval and management. When this is coupled with a native XDMS, you have an elegant, high-performance option to the complex and sluggish middle-tier conversions of your XML data using the traditional parsing approach with an RDBMS (relational database management system) SOA artifacts store.

Conclusion

As we have seen throughout this article, XML plays an important role in describing the key security standards for SOA. Persisting XML data, including security and organizational policies and secure messages described in XML, should be handled by an XDMS. Though many XML and SOA security standards are still evolving, an XDMS enables the implementation of SOA security standards today and minimizes disruption as the standards evolve. For example, XQuery can be utilized in parsing and updating these XML security documents that are persisted and managed in an XDMS. Furthermore, an XDMS can handle any type of XML data without prior knowledge of the XML Schema structure. This powerful functionality proves highly advantageous when handling XML messages and security documents from federated systems with different security approaches. An XDMS can persist these diverse documents, and, along with XQuery, transform and map the various security standards.

Additionally, an XDMS offers the full power to manipulate, browse, search, integrate, and aggregate enterprise data in an SOA. Hence, an XDMS powered with XQuery provides compelling benefits to secure your SOA.

We would like to thank Ajay Ramachandran, vice president, enterprise applications group at Raining Data, for technically reviewing this article.

About the author

Read more about Enterprise Java in JavaWorld's Enterprise Java section.