| One of the purposes of creating security standards is the ease of interoperability. Using security standards, developers have more flexibility to interoperate between Java and .NET applications and do not lock in with a specific vendor product. This section introduces security standards and specifications for interoperability using Web services with details: WS-Security, WS-I Basic Security Profile, XACML, WS-Policy, Web Services Policy Language, and Single Sign-on Metadata Exchange (SSO MEX). Table 13-1 provides a list of security standards and specifications that are relevant for Java EE .NET interoperability. Although WS-Policy and SSO MEX are not a security standards yet, they are important security specifications for Java EE .NET interoperability. Table 13-1. List of Security Standards and Specifications for Interoperability| | Security Standards | Security Specifications |
|---|
Application Security | Web Services Security (OASIS) | | | | WSI Basic Security Profile (WSI) | | Policy | XACML (OASIS) | | | | Web Services Policy Language (OASIS) | WS-Policy | Single Sign-on | | SSO MEX | Others (not covered in this chapter) | | WS-Trust | | | | WS-SecureConversation |
Web Services Security Web services security (WS-Security) is an approved standard to secure SOAP messages under OASIS. It leverages XML Digital Signature and XML Encryption for message integrity and confidentiality. WS-Security provides an abstract message security model that specifies how to protect a SOAP message in terms of a security token and digital signature. Security tokens are simply assertions of claims about the user identity and can be used to assert the binding between the authentication secrets, keys, or security identities. WS-Security currently supports a variety of security tokens, for example, user name token (aka password), binary token (such as the X.509v3 certificate or Kerberos ticket), and XML tokens. From a Java EE .NET interoperability perspective, WS-Security plays a key role because it defines a standard format where a Java and .NET application can exchange business data. Listing 13-1 shows a .NET program excerpt how to sign a message using a X.509 certificate. Listing 13-1. Sample .NET Program Excerpt Showing How to Sign a Message with an X.509 Certificate| using System; using Microsoft.Web.Services2.Security; using Microsoft.Web.Services2.Security.Tokens; using Microsoft.Web.Services2.Security.X509; using Microsoft.Web.Services2.QuickStart; namespace X509SigningClient { /// <summary> /// This is a sample which allows the user to send a message to /// a Web /// service that has been signed with an x.509 certificate. /// </summary> class X509SigningClient : AppBase { [MTAThread] static void Main(string[] args) { X509SigningClient client = null; try { client = new X509SigningClient(); client.Run(); } catch (Exception ex) { Error(ex); } Console.WriteLine( "Sample - .NET X.509 Signing Client" ); Console.WriteLine(); } public void Run() { // Create and configure Web service proxy // //ManufactureDelegate serviceProxy = new ManufactureDelegate(...); //ConfigureProxy(serviceProxy); ... // Fetch X.509 security token and generate asymmetric key // 'false' forces to use WSE sample certificate X509SecurityToken token = AppBase.GetClientToken(false); if (token == null) throw new ApplicationException ("Cannot retrieve security token!"); // Add the signature element to a security section on the // request // to sign the request serviceProxy.RequestSoapContext.Security.Tokens.Add(token); serviceProxy.RequestSoapContext.Security.Elements. Add(new MessageSignature(token)); // Invoke business service ... } } } |
A Java platform provides low-level and fine-grained programming APIs that generate XML signatures using the JSR 105 (XML signature) API (refer to Listing 13-2 for an example). In practice, developers do not use these fine-grained APIs directly to sign a message in WS-Security. There are tools available to implement WS-Security with coarse-grained programming APIs. For example, JWSDP version 1.5 provides a useful WS-Security security handler, SecurityEnvironmentHandler, that refactors the encryption, decryption, and the digital signing processing logic into handlers. It does not require developers to embed the common security processing logic into the application. Developers can simply turn on or off the security processing logic in a configuration file (refer to the next section, "Secure Object Handler Strategy"). Listing 13-2. Sample Java Program Excerpt Generating a Digital Signature| import javax.xml.crypto.*; import javax.xml.crypto.dsig.*; import javax.xml.crypto.dom.*; import javax.xml.crypto.dsig.dom.DOMSignContext; import javax.xml.crypto.dsig.keyinfo.*; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.OutputStream; import java.security.*; import java.util.Arrays; import java.util.Collections; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.transform.*; import javax.xml.transform.dom.DOMSource; import javax.xml.transform.stream.StreamResult; import org.w3c.dom.Document; import org.w3c.dom.Node; public class SigningClient { public static void main(String[] args) throws Exception { // Create digital signature factory String providerName = System.getProperty ("jsr105Provider", "org.jcp.xml.dsig.internal.dom.XMLDSigRI"); XMLSignatureFactory dsigFactory = XMLSignatureFactory.getInstance("DOM", (Provider) Class.forName(providerName).newInstance()); // Create document factory and object reference using SHA1 // digest Reference ref = dsigFactory.newReference("#object", dsigFactory.newDigestMethod(DigestMethod.SHA1, null)); DocumentBuilderFactory docFactory = DocumentBuilderFactory.newInstance(); docFactory.setNamespaceAware(true); Document doc = docFactory.newDocumentBuilder().newDocument(); Node text = doc.createTextNode("PO number"); XMLStructure content = new DOMStructure(text); XMLObject obj = dsigFactory.newXMLObject (Collections.singletonList(content), "object", null, null); // Create the SignedInfo SignedInfo signedInfo = dsigFactory.newSignedInfo( dsignFactory.newCanonicalizationMethod (CanonicalizationMethod.INCLUSIVE_WITH_COMMENTS, null), dsignFactory.newSignatureMethod(SignatureMethod.DSA_SHA1, null), Collections.singletonList(ref)); // Create a DSA KeyPair KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("DSA"); keyPairGen.initialize(512); KeyPair keyPair = keyPairGen.generateKeyPair(); // create key value using DSA public key KeyInfoFactory keyInfoFactory = dsigFactory.getKeyInfoFactory(); KeyValue keyValue = keyInfoFactory.newKeyValue(keyPair.getPublic()); KeyInfo keyInfo = keyInfoFactory.newKeyInfo(Collections.singletonList(keyValue); // create XML signature XMLSignature signature = dsigFactory.newXMLSignature(signedInfo, keyInfo,Collections.singletonList(obj), null, null); // create context using DSA private key DOMSignContext signContext = new DOMSignContext(keyPair.getPrivate(), doc); // Generate enveloping signature using private key signature.sign(signContext); ... } } |
WS-I Basic Security Profile Web Services Interoperability (WS-I)'s Basic Security Profile (BSP) version 1.0 (refer to [BSP] for details) is a draft specification that defines the semantics of using the elements of OASIS's Web Services Security and places constraints on its use to achieve interoperability. BSP includes the following key characteristics: Elements of a Secure SOAP Message BSP uses elements defined in the Web Services Security 1.0 specification and includes a secure envelope, secure message, security header, reference, digital signature, encrypted key, encryption reference list, encrypted key reference list, encrypted data, security token reference, internal security token, and timestamp. Secure Transport Layer HTTP over TLS 1.0/SSL 3.0 should be used for transport layer security. Though BSP does not prohibit use of any specific TLS or SSL ciphersuites, it recommends ciphersuites that support the AES encryption algorithm, for example, TLS_RSA_WITH_AES_128_CBC_SHA, and discourages ciphersuites that are vulnerable to man-in-the-middle attacks, for example, SSL_RSA_WITH_NULL_SHA. SOAP Message Security BSP places some constraints in the use of binary security tokens, for example, only Base64Binary encoding type is supported, and <wsse:BinarySecurityToken> with a single X.509 certificate in the element <wsu:Id> must have the ValueType value http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3. The ValueType element is interesting and important from the perspective of ensuring openness and interoperability because it is used to define customer bearer tokens, which is used, for instance, by the Liberty Alliance for single sign-on. Moreover, BSP defines the semantics of a creation timestamp (<wsu:Timestamp>) element to be used for each <wsu:Created> element but does not allow leap seconds. BSP also specifies the order of processing the signature and encryption blocks (that is, signature, encrypted key, and encryption reference list) within the <wsse:Security> headers so that the recipient gets the correct result by processing the elements in the order they appear. Username Token Profile BSP specifies the semantics regarding the use of a username token, for example, the <Type> attribute (such as Type='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText') must be specified to avoid any ambiguity of the element, <wsse:Password>. Another example is that Web Services Security does not fully describe the proper ValueType for the username token, and BSP uses the value http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-messagesecurity-1.0#UsernameToken for the attribute wsse:SecurityTokenReference/wsse:Reference/@ValueType. X.509 Certificate Token Profile Web Services Security supports three token types (namely, X509v3, x509PKIPathv1, and PKCS7) in the X.509 certificate token profile. BSP places some constraints to the profile, for example, when certificate path information is provided via either X509PKIPathv1 or PKCS7 formats, the sender must provide one of the X509PKIPathv1 or PKCS7 token types. In addition, when the element, <wsse:KeyIdentifier>, is used within a security token reference to denote an X.509 certificate token, the element, <wsse:KeyIdentifier>, must use the value http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier in the <ValueType> attribute. Use of XML Signature BSP places some constraints on the use of XML Signaturefor example, the enveloping signature is not allowed, and a detached signature should be used instead. BSP also recommends two key signature algorithms (hmac-sha1 and rsa-sha1) and one digest algorithm (SHA1) for interoperability. Use of XML Encryption BSP adds some constraints on the use of XML Encryptionfor example, an encrypted key <xenc:EncryptedKey> must precede any encrypted data in the same security header. Attachment Security BSP specifies some constraints on the SOAP with Attachments for interoperability, one of which is that secure message must conform to WS-I Attachment Profile 1.0. BSP also defines the semantics around the signed attachmentsfor example, reference to a signed MIME part must use a URI attribute of the form "cid:partToBeSigned", and encrypted attachmentsfor example, encrypted data referencing a MIME part must include a type attribute with the value of either "...#Attachment-Content-Only" or "...#Attachment-Complete".
XACML Business applications usually have custom security policies to determine which resources or business data a service requester can access. Some applications may tightly couple the access control processing logic with the business processing logic. This would make the access control policies very difficult to extend or customize. For Java and .NET applications running on different platforms, it is fairly important to have a generic, flexible, and adaptive policy framework that operates on both Java and .NET applications. When there is a change of access control policy, developers do not need to modify their program logic or recompile their programs. eXtensible Access Control Markup Language (XACML) version 2.0 is an approved security policy management standard under OASIS (refer to [XACML2]). Currently, it has both Java and .NET implementations. XACML is both a policy language and an access control decision request-response language encoded in XML. It is used to express authorization rules and polices and to evaluate rules and policies for authorization decisions. Moreover, XACML is used to make authorization decision requests and responses. In a typical application environment, a user wants to make a request to access certain resources. The Policy Enforcement Point (PEP) is a system or application that protects the resources. The PEP needs to check whether the service requester is eligible to access the resources. It sends the resources request to the Policy Decision Point (PDP), which looks up the security access control policies. XACML provides both a policy language and an access control decision request-response language to meet the security access control requirements. With XACML, the PEP forms a query language to ask the PDP whether or not a given action should be allowed. The PDP responds by returning the value of either Permit, Deny, Indeterminate (decision cannot be made due to some errors or missing values), or Not Applicable (the request cannot be answered by this service). XACML Components XACML provides a rich policy language data model to define flexible and sophisticated security policies. The following summarizes the key components in an XACML data model, [XACML2]: Policies A policy represents a single access control policy, expressed through a set of rules. Policies are a set of rules together with a rule-combining algorithm and an optional set of obligations. Obligations are operations specified in a policy or policy set that should be performed in conjunction with enforcing an authorization decision. Each XACML policy document contains exactly one Policy or PolicySet root XML tag. Policy Set A Policy Set is a set of policies or other Policy Sets and a policy-combining algorithm, and a set of optional obligations. Rules Rules are expressions describing conditions under which resource access requests are to be allowed or denied. They apply to the target (<Target>), which can specify some combination of particular resources, subjects, or actions. Each rule has an effect (which can be permit or deny) that is the result to be returned if the rule's target and conditions are true. Rules can specify a condition (<Condition>) using Boolean expressions and a large set of comparison and data-manipulation functions over subject, resource, action, and environment attributes. Target A Target is basically a set of simplified conditions for the Subject, Resource, and Action that must be met for a PolicySet, Policy, or Rule to apply to a given request. These use Boolean functions (explained more in the next section) to compare values found in a request with those included in the Target. If all the conditions of a Target are met, then its associated PolicySet, Policy, or Rule applies to the request. In addition to being a way to check applicability, Target information also provides a way to index policies, which is useful if several policies need to be stored and then quickly sifted through to find which ones apply. Attributes Attributes are named values of known types that may include an issue identifier or an issue date and time. Specifically, attributes are characteristics of the Subject, Resource, Action, or Environment in which the access request is made. For example, a user's name, their group membership, a file they want to access, and the time of day are all attribute values. When a request is sent from a PEP to a PDP, that request is formed almost exclusively of attributes, which are compared to attribute values in a policy to make the access decisions.
Example Listing 13-3 depicts a service request to access the URL http://www.supplychain.com/purchaseorder.html. The service requester is a buyer with the subject buyer@javadotnetinterop.com and the access rights group tradingPartner. Listing 13-3. Sample Service Request to Access a URL| <?xml version="1.0" encoding="UTF-8"?> <Request xmlns="urn:oasis:names:tc:xacml:2.0:context" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Subject> <Attribute AttributeId= "urn:oasis:names:tc:xacml:2.0:subject:subject-id" DataType= "urn:oasis:names:tc:xacml:2.0:data-type:rfc822Name"> <AttributeValue> buyer@javadotnetinterop.com </AttributeValue> </Attribute> <Attribute Attribute DataType= http://www.w3.org/2001/XMLSchema#string Issuer= "admin@javadotnetinterop.com"> <AttributeValue>tradingPartner</AttributeValue> </Attribute> </Subject> <Resource> <Attribute AttributeId= "urn:oasis:names:tc:xacml:2.0:resource:resource-id" DataType= "http://www.w3.org/2001/XMLSchema#anyURI"> <AttributeValue> http://www.supplychain.com/purchaseorder.html </AttributeValue> </Attribute> </Resource> <Action> <Attribute AttributeId= "urn:oasis:names:tc:xacml:2.0:action:action-id" DataType= "http://www.w3.org/2001/XMLSchema#string"> <AttributeValue>execute</AttributeValue> </Attribute> </Action> </Request> |
Listing 13-4 defines the security policy in XACML. The policy indicates that only service requesters with the e-mail address javadotnetinterop.com and the access rights group TRadingPartner can access the URL, http://www.supplychain.com/purchaseorder.html. Listing 13-4. Sample XACML Policy| <?xml version="1.0" encoding="UTF-8"?> <Policy xmlns="urn:oasis:names:tc:xacml:2.0:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Policy RuleCombiningAlgId= "urn:oasis:names:tc:xacml:2.0:rule-combining-algorithm:permit-overrides"> <Description> This policy states that trading partners with a valid domain name @javadotnetinterop.com should be able to submit purchase order online using the URL http://www.supplychain.com/purchaseorder.html Both successful and invalid read request are logged using Obligation. If users have a different domain name other than @javadotnetinterop.com, this policy will deny access. If users with a domain name @javadotnetinterop.com who are NOT trading partners this policy also deny their access. This policy illustrates use of "Condition" within a "Target" element to apply constraints to the read access for the requester who are Administrator only. It also provides an example of "Obligation" to log successful read and log invalid access. </Description> <Target> <Subjects> <Subject> <SubjectMatch MatchId= "urn:oasis:names:tc:xacml:2.0:function:rfc822Name-match"> <AttributeValue DataType= "http://www.w3.org/2001/XMLSchema#string"> javadotnetinterop.com </AttributeValue> <SubjectAttributeDesignator DataType= "urn:oasis:names:tc:xacml:2.0:data-type:rfc822Name" AttributeId= "urn:oasis:names:tc:xacml:2.0:subject:subject-id"/> </SubjectMatch> </Subject> </Subjects> <Resources> <Resource> <ResourceMatch MatchId= "urn:oasis:names:tc:xacml:2.0:function:anyURI-equal"> <AttributeValue DataType= "http://www.w3.org/2001/XMLSchema#anyURI"> http://www.supplychain.com/purchaseorder.html </AttributeValue> <ResourceAttributeDesignator DataType= "http://www.w3.org/2001/XMLSchema#anyURI" AttributeId= "urn:oasis:names:tc:xacml:2.0:resource:resource-id"/> </ResourceMatch> </Resource> </Resources> <Actions> <AnyAction/> </Actions> </Target> <Rule RuledocEmphStrong">ExecuteRule" Effect="Permit"> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <Action> <ActionMatch MatchId= "urn:oasis:names:tc:xacml:2.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> execute </AttributeValue> <ActionAttributeDesignator DataType= "http://www.w3.org/2001/XMLSchema#string" AttributeId= "urn:oasis:names:tc:xacml:2.0:action:action-id"/> </ActionMatch> </Action> </Actions> </Target> <Condition FunctionId= "urn:oasis:names:tc:xacml:2.0:function:string-equal"> <Apply FunctionId= "urn:oasis:names:tc:xacml:2.0:function:string-one-and-only"> <SubjectAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" Attribute/> </Apply> <AttributeValue DataType= "http://www.w3.org/2001/XMLSchema#string"> tradingPartner </AttributeValue> </Condition> </Rule> <Rule Rule Effect="Deny"/> <Obligations> <Obligation ObligationdocEmphStrong">LogSuccessfulExecute" FulfillOn="Permit"> <AttributeAssignment Attribute DataType= "http://www.w3.org/2001/XMLSchema#anyURI"> urn:oasis:names:tc:xacml:2.0:subject:subject-id </AttributeAssignment> <AttributeAssignment Attribute DataType="http://www.w3.org/2001/XMLSchema#anyURI"> urn:oasis:names:tc:xacml:2.0:resource:resource-id </AttributeAssignment> </Obligation> <Obligation ObligationdocEmphStrong">LogInvalidAccess" FulfillOn="Deny"> <AttributeAssignment Attribute DataType="http://www.w3.org/2001/XMLSchema#anyURI"> urn:oasis:names:tc:xacml:2.0:subject:subject-id </AttributeAssignment> <AttributeAssignment Attribute DataType="http://www.w3.org/2001/XMLSchema#anyURI"> urn:oasis:names:tc:xacml:2.0:resource:resource-id </AttributeAssignment> <AttributeAssignment Attribute DataType="http://www.w3.org/2001/XMLSchema#anyURI"> urn:oasis:names:tc:xacml:2.0:action:action-id </AttributeAssignment> </Obligation> </Obligations> </Policy> |
When applying the XACML security policy using Sun XACML Kit's sample policy engine (SimplePDP), the policy engine shows a positive policy evaluation result, and the service requester is granted access to the URL in question. Refer to Listing 13-5. Listing 13-5. Evaluating an XACML Policy| C:\XACML2\sunxacml-1.2\sample>java SimplePDP request\request.xml policy\policy.xml <Response> <Result ResourceID= "http://www.supplychain.com/purchaseorder.html"> <Decision>Permit</Decision> <Status> <StatusCode Value="urn:oasis:names:tc:xacml:2.0:status:ok"/> </Status> <Obligations> <Obligation ObligationdocEmphStrong">LogSuccessfulExecute" FulfillOn="Permit"> <AttributeAssignment Attribute DataType= "http://www.w3.org/2001/XMLSchema#anyURI"> urn:oasis:names:tc:xacml:2.0:subject:subject-id </AttributeAssignment> <AttributeAssignment Attribute DataType= "http://www.w3.org/2001/XMLSchema#anyURI"> urn:oasis:names:tc:xacml:2.0:resource:resource-id </AttributeAssignment> </Obligation> </Obligations> </Result> </Response> |
WS-Policy Policies are useful in specifying the conditions or assertions regarding interactions between Java and .NET interoperable applications. These policies can be defined for authentication, authorization, quality of protection, quality of service, privacy, reliable messaging, and service-specific options (such as bandwidth guarantee). For Java EE .NET interoperable solutions using Web services, there are two emerging policy-related specifications: WS-Policy and WSPL (Web services policy language). WS-Policy (Web Services Policy) framework is part of the Web Services roadmap and specifications (a.k.a., WS*) proposed by Microsoft, IBM, VeriSign, and others. It is primarily a policy language that defines polices for Web services. WS-Policy encodes the policy definition in XML using SOAP messages for data exchange. These Web services policies are a collection of "policy alternatives," which are a collection of policy assertions such as authentication scheme, privacy policy, and so forth. This policy framework is a flexible mechanism to define rules for executing Java and .NET applications even though they run on different software platforms and different underlying implementations. Currently, there is a draft JSR 265 specification for Web services policy (refer to www.jcp.org/en/jsr/detail?id=265&showPrint for details). Please note that WS-Policy is still not yet an open standard. Some extensions and usage of WS-Policy are now defined in the WS-SecurityPolicy specification. The new OASIS Web Services Secure Exchange (WS-SX) Technical Committee (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx) is working on finalizing a set of specifications based on WS-SecureConversation, WS-SecurityPolicy, and WS-Trust specifications. Unlike XACML, the WS-Policy specification does not restrict the policy definitions to access control or privacy. WS-Policy can be used to specify the type of security token, digital signature algorithm, and encryption mechanism for a SOAP message (for example, a purchase order message) or even partial contents of a SOAP message (a credit card number, for example). In addition, it can also specify data-privacy or data-confidentiality rules. Nevertheless, WS-Policy does not specify how to discover policies or how to attach a policy to a Web service. It relies on other WS* specifications (for example, WS-PolicyAttachment) to provide full functionality of policy management. Listing 13-6 shows an example of a WS-Policy that uses Triple DES and RSA OAEP (RSA Optimal Asymmetric Encryption Padding) encryption key algorithms. Listing 13-6. Sample WS-Policy File| <?xml version="1.0" encoding="utf-8"?> <configuration> <configSections> <section name="microsoft.web.services2" type="Microsoft.Web.Services2.Configuration.WebServicesConfiguration, Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> </configSections> <microsoft.web.services2> <security> <x509 storeLocation="CurrentUser" allowTestRoot="true" allowRevocationUrlRetrieval="false" verifyTrust="true" /> <binarySecurityTokenManager valueType="http://docs.oasis-open.org/wss/2004/01/oasis- 200401-wss-x509-token-profile-1.0#X509v3"> <sessionKeyAlgorithm name="TripleDES" /> <keyAlgorithm name="RSAOAEP" /> </binarySecurityTokenManager> <securityTokenManager xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis- 200401-wss-wssecurity-secext-1.0.xsd" qname="wsse:UsernameToken" /> </security> <diagnostics> <trace enabled="true" input="InputTrace.webinfo" output="OutputTrace.webinfo" /> </diagnostics> <policy> <cache name="policyCache.config" /> </policy> <tokenIssuer> <autoIssueSecurityContextToken enabled="true" /> </tokenIssuer> </microsoft.web.services2> </configuration> |
Under WS-Policy, there is a set of policy assertions for each policy domain. For example, the assertions for use with WS-Security are defined in WS-SecurityPolicy. Each specification or schema to be controlled or managed by WS-Policy requires definition of a new set of assertions. Under the WS-Policy model, a policy for Web services denotes conditions or assertions regarding the interactions between two Web services endpoints. The service provider exposes a Web services policy for the services they provide. The service requester decides, using the policies, whether it wants to use the service, and if so, the "policy alternative" it chooses to use. In other words, WS-Policy does not have the notion of a Policy Enforcement Point, which enforces policies, and a Policy Decision Point, which also determines policies. It leaves the policy enforcement and decision to the service providers and service requesters. Web Services Policy Language WSPL (Web Services Policy Language) is based on XACML and is currently a working draft in the OASIS XACML technical committee. It uses a strict subset of XACML syntax (restricted to Disjunctive Normal Form) and has a different evaluation engine than XACML. XACML evaluates the access-control policies with a given set of attributes and policies, while WSPL determines what the mutually acceptable sets of attributes are when given two policies. For a good introduction on WSPL refer to [Anne3]. WSPL has provided similar functionality to define policies for Web services. WSPL has the semantics of policy and operators, which allow comparison between an attribute of the policy and a value or between two attributes of the policy. The policy syntax also supports rule preference. There are three distinctive features in WSPL. First, it allows policy negotiation, which can merge policies from two sources. Second, policy parameter allows fine-grained parameters such as time of day, cost, or network subnet address to be defined in a policy for Web services. Third, the design of WSPL is flexible enough to support any type of policy by expressing the policy parameters using standard data types and functions. One main problem WSPL has addressed is the negotiation of policies for Web services. Negotiation is necessary when choices exist or when both parties, Web services consumers and service providers, have preferences, capabilities, or requirements. In addition, it is necessary to automate service discovery and connection related to policies. WSPL shares similar policy definition capabilities with WS-Policy. Listing 13-7 shows a policy defined in WS-Policy, which specifies the security token usage and type for the Web services. It uses the element, <ExactlyOne>, to denote the security token usage. Listing 13-7. Policy for a Security Token Usage and Type Defined in WS-Policy| <wsp:Policy> <wsp:ExactlyOne> <wsse:SecurityToken> <wsse:TokenType>wsse:Kerberosv5TGT </wsse:TokenType> <wsse:/SecurityToken> <wsse:SecurityToken> <wsse:TokenType>X509v3 </wsse:TokenType> <wsse:/SecurityToken> </wsp:ExactlyOne> </wsp:Policy> |
Listing 13-8 shows that the same policy can be expressed in WSPL. WSPL translates the policy requirements into two rules. This makes it more descriptive and extensible in the event that security architects and developers need to add more operators or constraints. Listing 13-8. Sample WSPL Policy Showing Two Rules that Need to Be Satisfied| <Policy Policy RuleCombiningAlgorithm="&permit-overrides;"> <Rule Rule Effect="Permit"> Condition Function> <AttributeValue DataType="&string;">Kerberosv5TGT</AttributeValue> <ResourceAttributeDesignator Attribute DataType="&string;"/> </Condition> </Rule> <Rule Rule Effect="Permit"> <Condition Function> <AttributeValue DataType="&string;">X509v3</AttributeValue> <ResourceAttributeDesignator Attribute DataType="&string;"/> </Condition> </Rule> </Policy> |
WS-Policy and WSPL share similar functional features for interoperable Java EE .NET solutions. Anderson has identified a few technical limitations of WS-Policy when compared with WSPL (refer to [Anne2] for details): Negotiation WS-Policy does not specify a standard merge algorithm or standard way to specify policy negotiation (for example, for merging policies from two sources). Specifications for domain-specific WS-Policy Assertions may describe how to merge or negotiate assertions, but these methods are domain-specific. Assertion Comparison Because there is no standard language for defining Assertions in WS-Policy, there is no standard way to describe requirements such as minimumPurchaseQuantity > 3000. Again, specifications for domain-specific WS-Policy Assertions may describe schema elements for such comparisons, but the implementation of these elements must be done on a domain-by-domain basis given there is no standard. Dependency WS-Policy is designed to depend on extensions. Each extension must be supported by a custom evaluation engine.
Web Single Sign-On Metadata Exchange (SSO MEX) Both Java and .NET platforms have different approaches in achieving single sign-on. Liberty and SAML protocols are open standards that have wide Java-based implementations. On the .NET side, WS-Federation is used to provide single sign-on functionality. To enable both sides of the single sign-on technologies to interoperate, a new protocol is defined to enable browser-based Web single sign-on between security domains that use different protocols such as Liberty ID-FF and WS-Federation. The Web Single Sign-on Metadata Exchange (Web SSO MEX) primarily specifies a protocol that is independent of the stack and a profile specifying the interoperability between Liberty Identity Federation Framework and WS-Federation. It is not restricted to .NET (or WCF) and Liberty. The Web SSO MEX protocol defines how a service queries an identity provider for the metadata regarding the identity-federation protocol suites supported by that identity provider. The Web Single Sign-on interoperability profile further describes how the Web SSO MEX protocol is used to enable interoperability between two particular protocol stacks: Liberty's ID-FF 1.2 browser POST profile and WS-Federation Passive Requestor Interoperability profile. Technology Challenges A service provider's identity provider may be supporting multiple identity providers, such as Liberty-based and WS-Federation-based identity federation solutions. Both identity management solutions have very different designs and implementations for account federation. For example, Liberty federates different accounts via identity mapping using opaque identifiers, while WS-Federation federates accounts via identity mapping using the Pseudonym Service. Handling of security tokens can be designed and implemented in different ways as well. For example, Liberty extends SAML assertions for communicating authentication and authorization security tokens between security providers, while WS-Federation uses X.509v3 and Kerberos profiles from the WS-Security specification. For details on the differences between Liberty and WS-Federation, please refer to [LibertyWSFed]. Use Case Scenario A sample use case scenario (refer to Figure 13-4) would be a Web supply chain portal that supports both Liberty-based and WS-Federation-based identity federation infrastructures. A buyer browses through the online catalog and places purchase orders with two different suppliers. One supplier uses Liberty identity federation framework, denoted in the circles in Figure 13-4, for their supply chain system, and the other supplier uses the WS-Federation identity federation protocol for their order management system, denoted in the triangles in the figure. Figure 13-4. Web portal use case scenario
Using the Web SSO MEX protocol, the Web portal, acting as the Identity Provider in this scenario, can identify which single sign-on protocol to work with. Each identity federation infrastructure manages its own security token information (such as single sign-on token, SAML assertion, session information, and authentication information). However, there is no data conversion, data exchange, or security token mapping between the two single sign-on systems. Many security vendors are creating products for security token mapping soon. For example, Sun Java System Access Manager (http://www.sun.com/software/products/access_mgr/) now can provide single sign-on token information between the two identity federation infrastructures. Figure 13-5 depicts a sequence diagram for the message flow between the client (buyer), the service provider (supplier), and the identity provider (Web portal): Upon successful authentication, the client selects the Target Service from the Web portal. The client indicates its Identity Provider to the Target Service (Step 1). The Target Service formulates the Identity Provider (Step 2) and issues a request for the supported identity federation protocol from the Identity Provider (Step 3). The Identity Provider returns the protocol suite document to the Target Service. The Target Service determines the appropriate protocol suite (Step 4). The Target Service begins to exchange documents or messages using the common protocol suite-based single sign-on operations (Step 5). In this step, multiple single sign-on operations are required, and these operations, such as authentication and authentication assertions, vary according to the single sign-on protocols used. The Target Service is now able to provide business service based on the user identity (Step 6).
Figure 13-5. Web SSO sequence diagram
The service provider indicates an identity provider by any of the following four methods: Special header in the HTTP request (EPR-base64) Query string parameter in the URL Custom mechanism (such as mapping table, user prompt) EPR constructed using DNS name for the requester (client)
Sample Web SSO MEX Message Listing 13-9 depicts a request message for Web SSO. Listing 13-9. Sample Web SSO MEX Message| <s12:Header> <wsa:Action> http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Request </wsa:Action> <wsa:MessageID> uuid:53daedfc-4c3c-38b9-ba46-2480caee43e9 </wsa:MessageID> <wsa:ReplyTo> <wsa:Address> http://client.javadotnetinterop.com/Endpoint </wsa:Address> </wsa:ReplyTo> <wsa:To>http://service.sun.com/IdentityProvider</wsa:To> <ssi:SsiProtocolSuiteHandler/> </s12:Header> <s12:Body> <wsx:GetMetadata> <wsx:Dialect> http://schemas.xmlsoap.org/ws/2005/04/SsiSuites </wsx:Dialect> </wsx:GetMetadata> </s12:Body> |
Listing 13-10 shows a response message to the MEX request message. Listing 13-10. Sample Web SSO MEX Reply| <s12:Header> <wsa:Action> http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Response </wsa:Action> <wsa:MessageID> uuid:73d7edfc-5c3c-49b9-ba46-2481caee4177 </wsa:MessageID> <wsa:RelatesTo> uuid:73d7edfc-5c3c-49b9-ba46-2480caee43e9 </wsa:RelatesTo> <wsa:To>http://client.javadotnetinterop.com/MyEndpoint</wsa:To> </s12:Header> <s12:Body> <wsx:Metadata> <wsx:MetadataSection Dialect='http://schemas.xmlsoap.org/ws/2005/04/SsiSuites' > <wsp:ExactlyOne> ... </wsp:ExactlyOne> </wsx:MetadataSection> </wsx:Metadata> </s12:Body> |
|