In this section, we will briefly introduce XACML and describe how it works with the SAML model. We will also describe the relationship of SAML to WS-Security.
XACML
The XACML TC is working under the OASIS consortium, and has the charter to develop an access control specification based on XML. The TC has taken the SAML authorization model as a jumping-off point and is developing a rich policy language and model to be used for access control. The intent is to work with the SAML specifi- cation and have seamless integration of the two specifications. As XACML develops its language and model, it may have to ask the SAML TC for some extensions to SAML. This is a contingency that both TCs expect and are prepared to address.
XACML is a general purpose access control language based on XML but not limited to work only with SAML. To this end, the XACML TC has specified its language so that it is insulated from the application environment by a canonical representation of the inputs and outputs. The XACML specification calls this insulating layer the XACML Context. The specification states that the actual methodology to convert from a specific application’s environment to XACML is out of scope, but suggests that one automated way is to use Extensible Stylesheet Language Transformations (XSLT).
In SAML, we have seen the definition of an authorization request, a reply, and an authorization assertion. These permit you to construct a simple request to ask the ques- tion: Can this subject perform this action on this resource? XACML’s intent is to refine and expand the SAML authorization request to work with the access control model and a language it is developing.
WS-Security
SAML is used in a SOAP profile that is being developed by another OASIS technical committee, the Web Services Security TC. That profile uses a specification called WS- Security, which we discussed in Chapter 4, “XML Security and WS-Security.” The 130 Chapter 5
SAML TC has submitted a specification to the Web Services Security TC to include a SAML token. The Web Services Security TC has accepted this proposal and is working it into the WS-Security specification.
SAML and WS-Security are naturally complementary. SAML assertions need a pro- tocol to be transmitted from one application to another in some secure, standard way. WS-Security can address this need, since it is designed to transmit security data from one application to another application in a SOAP header.
WS-Security defines an XML document that, among other things, identifies tokens that carry security information. WS-Security has defined some tokens, such as the
UserNametoken element, which carries the username and optionally the password, and a BinarySecurityToken, which could contain an X.509 certificate or a Kerberos ticket. The specification permits other tokens to be defined, such as a SAML assertion. Con- sequently, there are few technical obstacles for aligning SAML and WS-Security.
In Chapter 10, we will provide further detail on how SAML and WS-Security sup- port interoperability, and give examples of the combined approach.
Summary
This chapter has described an XML-based specification, SAML, that defines the syntax and semantics of statements supporting the security of message exchanges in a dis- tributed system. The statements are assertions by trusted third parties relating to the authentication, attributes, and/or authorization of principals in a distributed system.
The set of distributed security problems that SAML helps solve includes: Interoperability. The ability to communicate between security systems within
the different tiers that support enterprise applications
Privacy. The ability to protect a user’s identity and personal data, such as credit card numbers and medical records, from unwanted disclosure when making a request
Federation. The ability of different companies to securely exchange requests and data with each other
SSO. The ability to log in once and use that login to access disparate applications We described two aspects of the SAML specification:
■■ The SAML assertions and how they may be used
■■ The means by which the SAML assertions can be transported from application to application, called SAML profiles, and the means by which a SAML asser- tion can be requested and returned from a trusted third party, called SAML bindings
We delved enough into the SAML specification so that you, as a user of SAML asser- tions and request/replies, could understand their capabilities and make judgments on how they are being supported by a security service that you might contemplate using or purchasing.
We described a project called Shibboleth that addresses some solutions to some of the hard problems faced when one is trying to achieve secure, distributed computing
using SAML. The problems that we talked about were privacy, federation, and single sign-on.
SAML provides an important contribution to solving the overall problem of secure Web Services interoperability. SAML’s contribution to interoperability is its ability to define a standardized format for security information, and a standardized way of transmitting security data among different applications. A prime requisite for any hope of interoperability, beyond proprietary bridges, is to have a standard credential that different tiers and security models know how to interpret.
The next chapter will discuss principles for securing Web Services that will tie together the security concepts we introduced in the last few chapters: XML security, WS-Security, and SAML.
133
In earlier chapters, we defined security services and explained how they could be pro- vided. In this chapter, we would like to focus on several of these security services and describe them within the context of Web Services. We will also look in more detail at possible security solutions and determine how they fit into security for Web Services. We will do this by considering a Web Services usage scenario and seeing how the secu- rity solutions can be applied.
For this discussion, we will limit our scope to the Web Services interface. That is, we will look at the security of XML-based SOAP messages, as they are communicated from one processing domain to another. This does not mean that we aren’t concerned about events that occur before or after communication across the interface. At the Web Services interface, we are concerned about authentication, authorization, confidential- ity, and integrity.