Featured White Papers

• Measuring Risk to Improve Java Software Quality
• 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

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

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 5 of 6

SAML

The XML Security Assertion Markup Language defines an XML vocabulary for sharing security assertions, including authentication and authorization assertions, enabling single sign-on and third-party management of these functions. It also defines a request/response protocol definition and an XML protocol (SOAP) binding. The SAML specification defines a general assertion framework, allowing assertions to be given validity time periods and allowing assertions to be targeted to specific audiences (avoiding the potential for misuse). Assertions are associated with a given "subject" or named entity.

SAML is a standard way of exchanging security and related data across heterogeneous, distributed systems crossing domain boundaries. Authorization and audit trail are familiar security services. In the past, most systems were designed under the assumptions that a single system would posses all of the information necessary to make access control decisions and all the data would be recorded in the audit trail. However, large-scale distributed systems are always built by multiple organizations with a mixture of products. Thus, users may be authenticated by different authorities using different methods. In addition, different authorities retain different information about user properties and attributes. Centralizing all capabilities and information is just not practical. SAML provides standard formats to express authentication and user attributes, and the protocols to request and receive.

The SAML specification defines:

• An XML vocabulary for expressing authentication and authorization assertions, allowing statements to be passed among parties about how and when authentication and authorization occurred.
• A request response protocol for conveying SAML assertions, as well as an XML protocol (SOAP) binding.
• Unique identifiers (URNs) for different authentication mechanisms and authorization actions.
• How digital signatures are associated with assertions.
• SAML Token Profile, which describes how SAML assertions are carried in and referenced from <wsse:security> headers, and how SAML assertions are used with XML-Signature Syntax and Processing to bind the statements of the assertions (e.g., the claims) to a SOAP message.

XACML

Although SAML provides a mechanism for making authentication and authorization assertions, and conveying these assertions using XML, a vocabulary is also required for expressing the rules needed to make authorization decisions. XML Access Control Markup Language was created specifically for expressing authorization rules.

XACML is a language for expressing access control policies; in other words, it protects content in data exchange. Access control lists (ACLs) lack the ability to express the complex policies often required in real-world systems. As a result, access control policies are often embedded into application code. This complicates the changing of policies or even discovering what policies are being enforced.

XACML is capable of using practically any available information to decide if access to a resource should be permitted. It can also associate additional actions, called obligations, with the decision—for example, requiring that the requested data be destroyed after a certain period.