7.5 Recent Web Services Security Initiatives
| The following sections summarize the major design features of recent Web Services security initiatives. When reviewing these initiatives for implementation, it is important to consider the ease of the implementation, the stopgap measure if the commercial implementation is not ready, and the migration roadmap from an existing stopgap implementation to the mature standard. This book does not intend to cover the program code or XML specifications in detail. Examples are given to illustrate the implementation and tools. The resource list at the end of this chapter provides some pointers with details. 7.5.1 WS-SecurityBackgroundIBM, Microsoft, and VeriSign submitted a new Web Services security specification on April 5, 2002, that is intended to consolidate previous security specifications, including Microsoft and IBM's SOAP-SEC, security tokens, encryption specifications, Microsoft's WS-Security, and WS-license (refer to Figure 7-7). From the details of the specification ( http://www-106.ibm.com/developerworks/library/ws-secure/ ), it focuses on converging the PKI-based and Kerberos-based authentication and encryption technologies used for SOAP messaging. This addresses the divergence of the current Web Services security implementation using X.509v3 digital certificates and .NET PASSPORT. It stated in Section 1.1.2 that it does not deal with authentication across different exchanges (compare SAML), key exchange, or establishing trust (compare XKMS). Figure 7-7. WS-Security Roadmap OASIS's Web Services Security Technical Committee has taken up the ownership to further work on Web Services security based on the WS-Security roadmap ( http://www.oasis- open .org/ committees /wss/ ). Currently, there are new draft core specifications and profile documents published (for example, http://www.oasis-open.org/committees/wss/documents/WSS-SOAPMessageSecurity-11-0303-merged.pdf ). OASIS has a concise highlight of the history and changes at http://xml.coverpages.org/ws-security.html . Some vendors have also provided an early release of WS-Security toolkits (such as Microsoft's Web Services Enhancement and IBM's Web Services Toolkit) and demonstrated an interoperability test between them in February of 2003 ( http://www.cbdiforum.com/public/news/index.php3?id=1192 ). Design FeaturesWS-Security differentiates unsigned security tokens (that is, user name and password) from signed security tokens (that is, X.509v3 certificates and Kerberos tickets). It uses two new tags ” <SecurityTokenReference /> and <BinarySecurityToken /> ”to support different security tokens. Figure 7-8 is an example modified from the original WS-Security specification. The example shows a stock symbol in a SOAP message, which consists of a SOAP header (with a security token and a digital signature) and a SOAP body (the payload, or the stock symbol itself). The bolded passages highlight some of the changes from the XML Signature specification. Figure 7-8 Sample WS-Security File<?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <S:Header> <m:path xmlns:m="http://schemas.xmlsoap.org/rp"> <m:action>http://bar.com/getQuote</m:action> <m:to>http://bar.com/stocks</m:to> <m:from>mailto:foo@bar.com</m:from> <m:id>uuid:61a8f5c2-14be-3a40-a13f-5b750540abc8</m:id> </m:path> <wsse:Security> <wsse:BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary" Id="X509Token"> Ksdfjs723ekldfsj... </wsse:BinarySecurityToken> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm= "http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference> <ds:Transforms> <ds:Transform Algorithm= "http://...#RoutingTransform"/> <ds:Transform Algorithm= "http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>UFDYsdf...</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> XMdfihdfdsl... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </S:Header> <S:Body> <myService:StockSymbol xmlns:myService="http://bar.com/payloads"> SUNW </myService:StockSymbol> </S:Body> </S:Envelope> Figure 7-9 is an example, based on the same contents modified from the XML Signature specification. It is shown here for easy comparison with the WS-Security specification (as in Figure 7-8). Figure 7-9 Sample XML Signature<?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" <S:Header> <Signature Id="myXMLSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>UFDYsdf...</DigestValue> </Reference> </SignedInfo> <SignatureValue>XMdfihdfdsl...</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue> <P>...</P><Q>...</Q><G>...</G><Y>...</Y> </DSAKeyValue> </KeyValue> </KeyInfo> </Signature> </S:Header> <S:Body> <myService:StockSymbol xmlns:myService="http://bar.com/payloads"> SUNW </myService:StockSymbol> </S:Body> </S:Envelope> Although the digital signature construct <ds:Signature /> is similar to the XML Signature, WS-Security does not use Enveloped Signature Transform or the Enveloping Signature in the XML Signature specification. WS-Security reuses the existing XML Encryption. When implementing WS-Security, developers need to detect any security threats, such as replays of the SOAP messages with security information. They can incorporate the use of timestamp, sequence numbers , expirations, and message correlations into the application design. IBM's Web Services Toolkit (WSTK) version 3.3.2 uses Apache Axis's handlers, namely "com.ibm.wstk.axis.handlers," to implement WS-Security XML Signature. The client generates a digital signature by invoking "org.apache.axis. utils .Admin" with a Web Services Deployment Descriptor (WSDD). java -cp "%WSTK_CP%" org.apache.axis.utils.Admin client dsig_client_deploy.wsdd dsig_client_deploy.wsdd (extracted from a demo program from WSTK 3.1), as shown in Figure 7-10, contains the target Web Service name and the Axis signer handler. No additional programming needs to be made. This is a good alternative to implement SOAP message-level security. Figure 7-10 Sample Digital Signature Client WSDD File [View full width] <deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org ImplicationBeyond WS-Security, IBM and Microsoft in their Web Services security roadmap ( http://www-106.ibm.com/developerworks/ webservices /library/ws-secmap/ ) have introduced a plan for new security specifications that supports defining policies, establishing trust and ensuring data privacy, secure conversation, federation of identities, and authorization. These new security specifications are also supported by IBM's XML Security Suite ( http://www.alphaworks.ibm.com/tech/xmlsecuritysuite ), IBM's Emerging Technologies Tool Kit or previously Web Services Tool Kit version 3.3.2 ( http://alphaworks.ibm.com/tech/ettk ), and Microsoft's CAPICOM ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/Security/capicom_reference.asp ). Nevertheless, they also overlap with existing security initiatives XKMS and SAML under Project Liberty. Thus, Web Serv-ices security becomes another battlefield between software vendors. WS-Security cannot be isolated without the context of the big picture from IBM and Microsoft's security roadmap. Though the current roadmap is the first step to defining a comprehensive Web Services security strategy, it has not covered aspects of integration and interoperability between different security standard variants, platform security and security hardening, and threat profiling. From the customer perspective, the convergence of different security standards is beneficial. Because these new security specifications are still evolving, risk-aversive customers may not be ready to adopt them. Customers face the risk of not implementing PKI-based or Kerberos-based authentication and encryption and the dilemma of painfully migrating to the industry security standard in the future. What may be useful to customers would be a migration technology (such as XML stylesheet mapping) to map different security schema or message constructs of these variant technologies. BenefitsWS-Security converges two different technology platforms and makes interoperability between .NET and Open Systems much easier. Developers may find WS-Security attractive because there are supporting implementations available to the developer desktop immediately, without waiting for long-due security standard specifications. 7.5.2 XKMSBackgroundXML Key Management Service (XKMS) is also considered part of the so-called Second Generation PKI. VeriSign, Microsoft, and webMethods contributed the draft specification to W3C. It is also part of the bigger XML Trust Service initiative ( http://www.xmltrustcenter.org ) sponsored by VeriSign. XKMS is intended to simplify the integration of PKI and digital signatures with XML applications. This is done by enabling the XML applications to delegate trust-processing decisions to a "specialized trust processor." Design FeaturesXKMS is a security specification ( http://www.w3.org/TR/xkms2/ ) depicting key registration, key retrieval, key revocation, and validation of key information. It supports different Trust Domains. There are two major components in XKMS: X-KISS and X-KRSS (refer to Figure 7-11). Figure 7-11. XKMS Tiered Models Figure 7-11 summarizes five tiered models defined in the XKMS version 1.0 specification ( http://www.w3.org/TR/xkms/ ). Tier 0 XKMS denotes there is no trust service. The applications on both ends need to handle the authentication and generation of digital signatures. Under Tier 1 XKMS, the applications on both ends will provide authentication service, and the client will validate the digital signature. Under Tier 2 XKMS, there is a validation service available with service reporting capabilities. The client can issue a query to the trust service in order to validate the key. Tier 3 XKMS will help define a long- term trust relationship to establish and manage assertion service. Tier 4 XKMS will help manage the status of assertions. Tier 3 and Tier 4 XKMS are currently removed from the XKMS version 2.0 specification. XML Key Registration Service Specification (X-KRSS)This is a key pair holder to register a key pair. Key pairs can be generated in advance, upon a client request. The registration protocol may be used to recover private keys. These features are important aspects of issuing and managing key pairs stored in security tokens, such as digital certificates. Before X-KRSS is available, key registration and retrieval are vendor-specific. There are some variations in the details by security token storage devices. XML Key Information Service Specification (X-KISS)This is a relying party to locate and validate key information associated with a digital signature. It supports the current Directory Server, Certificate Authority, Registration Authority, and Validation Authority infrastructure. X-KISS allows signers to communicate to a verifier which public key to select, using <ds:KeyInfo />, which contains public signing key information (such as key name and key value) within the signature block of the XML message. Besides, it also allows substituting or supplementing <ds:KeyInfo /> if the property of the key information is cryptographically bound to the digital signature. Figures 7-12 and 7-13, extracted from the original XKMS specification, show an XKMS key location service request and response for Tier 1 service model (applications perform key information processing). In this scenario, the client sends a locate key request to the trust service with the tag "<Locate>" (Figure 7-12 shows the service request to locate a key). The trust service processes the locate key request, and relays it to the server with the tag "RetrievalMethod." The key is returned to the client with the tag "<LocateResult>" (Figure 7-13 shows the result of locating the key). Figure 7-11 also shows a sequence diagram that illustrates the processes of locating the key and returning the key result. Figure 7-12 XKMS Example 1 ”Locate a Key [View full width] <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http: Figure 7-13 XKMS Example 2 ”Return the Locate Key Result [View full width] <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http: Figures 7-14 and 7-15, extracted from the original XKMS specification, show an XKMS client request and response for Tier 2 service model (use of validation service). Figure 7-14 XKMS Example 3 ”Validate a Key [View full width] <?xml version="1.0"?>`,/kmp:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope Figure 7-15 XKMS Example 4 ”Return the Validate Key Result [View full width] <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http: Examples of XKMS implementation include VeriSign's Trust Services Integration Kit ( http://www.xmltrustcenter.org/developer/verisign/tsik/index.htm ) and Evincible's INK. ( http://www.evincible.com/products/ink.asp ). The following examples are Locate and Validate XKMS services using VeriSign's Trust Service Integration Kit (TSIK) version 1.1 on Windows 2000. To locate the key information, developers can use the method XKMSLocate(keyName, responses) or XKMS Locate(publicKey, responses) and XKMSLocateResponse lr = locate.sendRequest (transport) to return the Locate service response in an XML message. The Locate XKMS service partial code using TSIK looks like Figure 7-16. Figure 7-16 Sample XKMS Locate Client String responses[[]] = {XKMSLocate.KeyName, XKMSLocate.KeyValue}; XKMSLocate locate = null; if (keyName != null){ locate = new XKMSLocate(keyName, responses); } else { locate = new XKMSLocate(publicKey, responses); } XKMSLocateResponse lr = locate.sendRequest(transport); System.out.println("Response status is "+lr.getStatus()); Running the sample XKMS client to locate key information from the TSIK will render the result as in Figure 7-17. Figure 7-17 Running Sample XKMS Client to Locate Key Information [View full width] D:\Dev\Test\tsik1_0\samples\xkms>java SampleXKMS Client http://interop-xkms.verisign.com To validate the key information, developers can use the method XKMSValidate (keyName, responses) and XKMSValidateResponse vr = validate. sendRequest(transport) to return the validation response in an XML message, as in Figure 7-18. Figure 7-18 Running Sample XKMS Client to Validate Key Information String responses[[]] = {"KeyName", "KeyValue", ValidityInterval", "KeyUsage", "Status"}; XKMSValidate validate = null; if (keyName != null) { validate = new XKMSValidate(keyName, responses); } else if (cert != null) { validate = new XKMSValidate(cert, responses); } else { validate = new XKMSValidate(publicKey, responses); } XKMSValidateResponse vr = validate.sendRequest(transport); Running the sample XKMS client to validate key information from the TSIK will render the result in Figure 7-19. Figure 7-19 Result of Validating Key Information From an XKMS Client [View full width] D:\Dev\Test\tsik1_0\samples\xkms>java SampleXKMS Client http://interop-xkms.verisign.com/xkms/Acceptor.nano validate "http://xkms.verisign.com ImplicationMany existing key management and PKI implications deployed in the last two years do not support X-KRSS and X-KISS. Most of them use PKI vendor's Java technology implementation. Unless customers change their business model or Trust Domains, it is difficult to envision migration to XKMS just for standards compliance reasons, at least in the near future. One of the criticisms of XKMS is the complexity of the implementation. This includes awareness and understanding of the PKI and XML technology required to implement XKMS Web Services applications. Besides, the migration from the first-generation PKI implementation (that is, non-XKMS) to XKMS has not yet been well realized. As key management and digital signatures are the essential elements for implementing secure Web Services applications, XKMS is attractive to customers who have not yet implemented PKI technology. Customers can choose between the business model of implementing an in-house Certificate Authority (which requires lengthy documentations such as Certificate Policies and Certification Practice Statement) or outsourcing to an external Certificate Authority using XKMS standards (which appears to have lower cost of ownership and is easier for interoperability with external business partners ). The original XKMS specification has identified a few security risk areas, including replay attacks and Denial of Service. In essence, developers should include a design that does not allow reusing previous XKMS responses (for example, use of message serial number for identification, timestamps, and processing XKMS requests only with authenticated sources). The quality and reliability of XKMS depends on the design and implementation, not on the specification or toolkit. BenefitsX-KRSS addresses the issue of vendor-specific PKI implementation and provides an alternative to managed PKI service. X-KISS decouples the dependency of the client support of PKI. It also provides PKI support for mobile devices. 7.5.3 SAMLBackgroundSecurity Assertion Markup Language (SAML) is designed to enable the secure exchange of authentication, authorization (entitlement), and profile information between trading partners across heterogeneous platforms. This includes Single Sign-on within the internal organization or across enterprises and is independent of the underlying security infrastructure. SAML is derived from two previous security initiatives: Security Services Markup Language (S2ML) and Authorization Markup Language (AuthXML). Before SAML emerged, customers used proprietary interfaces, proprietary Single Sign-on vendor products, or directory-based products to address Single Sign-on within an enterprise. Cross-enterprise Single Sign-on has been a challenge for B2B integration. SAML is a key element in a Network Identity solution because it can collaborate and integrate with Federated Identity services (different authentication and authorization infrastructures ). The SAML Issuing Authority may be a third-party security Service Provider (such as Microsoft PASSPORT, XNSORG, or DotGNU) or Project Liberty alliance (a list of the founding members can be found at http://www.projectliberty.org/membership/members.asp ). It is also a core part of Web Services security, if we put SAML, XKMS, and WS-Security into a bigger picture. Design FeaturesSAML has a good architectural model that depicts a domain of Credential Collector, Authentication Authority, Session Authority, Attribute Authority, and Policy Decision Point. Figure 7-20 depicts a scenario where a system entity (client) wants to send an application request to access a system resource. The system entity presents its user credentials to the Credentials Collector, who will authenticate with the associated Authentication Authority (authentication assertion), the Attribute Authority (attribute assertion), and Policy Decision Point (authorization decision assertion) before the system entity can be granted access (Policy). The Policy Enforcement Point will process the application request based on the access rights granted in the Policy. All assertion requests are represented in SAML. Figure 7-20. SAML Domain Model Client requests for access (for example, credential or authentication assertion) come from a System Entry Point (refer to the System Entity in Figure 7-20), routed to different Authorities where authenticated and authorized requests will be routed to the relevant Policy Enforcement Point for execution. These architectural entities resemble different instances of Certificate Authority, Registration Authority, and Directory Server in real life, within an enterprise, external trust service, or trading partners. For example, the Credential Collector is like a RADIUS protocol that front-ends the authentication process and passes to the Directory Server (or Authentication Authority) relevant user credentials for authenticating the login. SAML differentiates Attribute Assertion and Decision Assertion within Authentication Assertion. Architecturally, SAML assertions are encoded in an XML package and consist of Basic Information (such as unique identifier of the assertion and issue date and time), Claims (document describing how the assertion makes claims for Authorization and Key Delegation applications), Conditions (dependency or rule for the assertion), and Advice (specification of the assertion for policy decision). SAML messages bind to SOAP as the underlying transport. SAML uses SOAP-RPC for invoking different assertions. During the login process, SAML allows credentials to be collected from different types of devices, such as mobile phone (for example, Systinet supports this mobile device implementation using a WASP Card [a virtual smart card that stores user credentials] as depicted in http://www.theserverside.com/resources/article.jsp?l=Systinet- web-services -part-6 ). SAML assumes the use of session management for authentication and authorization (entitlement). Figure 7-21 shows a SAML request sent from a relying party and requesting password authentication by the issuing party. The Issuing Authority (Service Provider) asserts that the client request has been authenticated and thus returns with a SAML response (see Figure 7-22). Figure 7-21 Sample SAML Message to Request Password Authentication<samlp:Request MajorVersion="1" MinorVersion="0" RequestID="1fgtTGzMXSqpN++/LcFpBmZWrQg="> <samlp:RespondWith>AuthenticationStatement</samlp: RespondWith> <samlp:AuthenticationQuery> <saml:Subject> <saml:NameIdentifier Name="test"/> <saml:SubjectConfirmation> <saml:ConfirmationMethod> http://www.oasis-open.org/committies/security/docs/draft-sstc-core-25/password </saml:ConfirmationMethod> <saml:SubjectConfirmationData> cGFzc3dvcmQ= </saml:SubjectConfirmationData> </saml:SubjectConfirmation> </saml:Subject> </samlp:AuthenticationQuery> </samlp:Request> Figure 7-22 Sample SAML Response ”Password Authenticated [View full width] <samlp:Response InResponseTo="1fgtTGzMXSpqN++/ LcFpBmZWrQg=" MajorVersion="1" MinorVersion="0" ResponseID="upuSGdmqx7ov01mExYlt+6bDCWE="> <samlp:Status> <samlp:StatusCode Value="samlp:Success"/> </samlp:Status> <saml:Assertion AssertionID="+1UyxJDBUza+ao+LqMrE98wmhAI=" IssueInstant="2002-03-03T14:33:58.456" Issuer="WASPCard" MajorVersion="1" MinorVersion="0"> <saml:Conditions NotBefore="2002-03-03T14:33:58.466" NotOnOrAfter="2002-03-03T15:03:58.466"/> <saml:AuthenticationStatement AuthenticationInstant="2002-03-03T14:33:55.201" AuthenticationMethod="http://www.oasis-open.org/committies/security/docs Examples of vendors supporting SAML implementation include Sun Microsystems' Sun ONE Identity Server, Entrust's getAccess Portal, Systinet's WASP Secure Identity, Securant's RSA Cleartrust, Entegrity's AssureAccess, and Netegrity's jSAML Toolkit. ImplicationOne concern of SAML is related to how it ensures trust between client and SAML entities and perhaps how to register SAML entities. According to the SAML-SOAP binding specification, SAML assumes that some system components will perform authentication for the SAML requester. Thus, it does not enforce any authentication between the SAML requester and responder or mandatory encryption to protect the SAML message contents. Thus, the quality and the robustness of the security implementation will vary by each customer's implementation. If a customer chooses to use strong authentication options (such as smart card with X.509v3 certificate for authentication) and data encryption, then the quality of the security implementation will be higher. Another area of concern is threat profiling, which was not articulated in early draft specifications. A very good discussion on the threat models for SAML messages and their countermeasures can now be found in Mishra's SAML binding specification paper and McLaren's SAML security consideration paper in http://www.oasis-open.org/committees/security/docs . The integration of an existing security infrastructure with SAML is not clearly articulated in the current SAML specifications. Existing customers who want to implement SAML will be interested in the migration roadmap (for example, what SAML components to buy versus build or what SAML plug-ins are available for Web servers and Directory Server) and implication (for example, upgrade effort for Policy Server and the development impact to existing applications in order to support SAML). Such impact may be much clearer after the final SAML specifications are fully implemented by major security vendors. Baltimore has a good paper on SelectAccess ( http://www.baltimore.com/resources/whitepapers.asp ) to depict how its SAML implementation integrates with its existing security infrastructure using a SAML plug-in. This may give us some ideas of the potential impact. BenefitsThe immediate benefit is the capability for Single Sign-on within the enterprise and across enterprises (B2B integration). 7.5.4 Project LibertyBackgroundProject Liberty ( www.projectliberty.org ) is a multi-industry business alliance established to define and promote security standards for network identity, network authentication, and network authorization (entitlement). There is large industry clout behind the supporting community, including AOL and Sun Microsystems. The premise of these security specifications is to provide a federated identity across enterprises that are connected on the Internet. This enables distributed data to be accessible by the "rightful" owner (entitlement) and allows multiple authenticators where merchants can retain control of transaction requirements. More importantly, Project Liberty supports multiple device and platform infrastructures for easier integration and interoperability. Please note that there are recent discussions (for instance, http://idevnews.com/CaseStudies.asp?ID=36 , http://www.eweek.com/article2/0,3959,425843,00.asp ) about the convergence of Project Liberty and other Web Services security specifications under OASIS. It is anticipated that OASIS would work closely to bridge the gaps between different security specifications in the next few months, which can benefit the user community. Design FeaturesThe initial proposal of Project Liberty includes the following stages: Single Sign-on for e-Wallet applications (which involves use of context-sensitive cookies and multi-authenticator systems), Federated Data Exchange (which uses extensive schema with mappings between partners, and strong cryptographic mechanisms between trading partners), B2B Transaction Support (which provides asynchronous communication and non- repudiation ), and Web Services as end-points (distributed redundant data for identity theft protection). Figure 7-23 summarizes the Liberty concept in the use of cross-domain Single Sign-on. There are three key actors: User Agent (aka User, security agent), Service Provider (provider of services to users), and Identity Provider (provider for identifying user identity). User Agent sends an HTTP request to Service Provider for Single Sign-on (step 1). Service Provider responds by redirecting to Identity Provider (step 2). User Agent sends a request to Identity Provider (step 3). Identity Provider responds by redirecting to Service Provider (step 4). User Agent sends an authentication request to Service Provider with URI (step 5). Figure 7-23. Liberty Concept ImplicationJava continues to be the underlying framework and tool for implementing Project Liberty. J2SE version 1.4 Platform Security now incorporates many key elements to support the development of these security features, including Java Authentication and Authorization Service (JAAS), Java Secure Socket Extension (JSSE), Java GSS, Certification Path (CertPath), and Java Cryptographic Architecture (JCA)/Java Cryptographic Extension (JCE). JAAS provides a Kerberos login module, and Java GSS-API provides functionality to support Kerberos-based authentication. JSSE provides an API to support SSL and TLS, which is a crucial transport layer for SOAP messaging and for mobile commerce. CertPath provides certificate chain validation and LDAP-based certificate validation. JAAS provides Single Sign-on support for Kerberos and digital certificate-based authentication and authorization. Early discussions of Project Liberty have involved SAML, XML Encryption, and XML Signature elements. Some vendors have announced the availability of their commercial implementation, such as the Sun ONE Identity Server. Microsoft PASSPORT appears to be at the other end of the camp, and there are discussions about incorporating Liberty support by PASSPORT in Liberty 1.1 specification. With the publication of IBM and Microsoft's WS-Security roadmap in April of 2002, it remains to be seen whether the proposed WS-Security roadmap will leverage, converge, or diverge with Project Liberty. Difference Between Liberty and SAMLLiberty extends the SAML schema for authentication assertion. It adds mobile client support and digital certificates (Public Key Infrastructure) for identity assertion. However, the initial phase of Liberty does not include Authorization Assertion. SAML has included both authorization and attribute assertions. Both Liberty and SAML support Single Sign-on requirements, but each has a different focus. And they are not identical. Please refer to the Liberty specifications for details. BenefitsThe benefits of Project Liberty come from vendor- and technology-platform neutrality. This will also expedite an industry-wide implementation of national identity and federated identity between trading partners for B2B integration. 7.5.5 Other InitiativesThe OASIS ( http://www.oasis-open.org/committees/security/index.shtml ) and XML Trust Center ( http://www.xmltrustcenter.org/index.htm ) Web sites identify some other initiatives. Among these initiatives, XML Access Control Markup Language (XACML), under OASIS, defines policies of using and accessing different parts of XML messages. IBM is driving this using its product, XML Security Suite. Some early initiatives have either been superseded by the current Web Services security specifications or slowed down. For example, XML Authorization Markup Language (XAML) was proposed in 2000 to support transaction authority, but SAML has emerged to provide a broader functionality. 7.5.6 Some Web Services Security ToolsThe following are some examples of useful Web Services security tools that are publicly available. These are not exhaustive, but they are fairly handy for understanding the new technology, evaluation, and Proof of Concept.
7.5.7 Design ConsiderationsDigital Signature and Signing ServerSome customers implement a Signing Server to generate a digital signature for the client, instead of generating from the client browser. Figure 7-24 depicts a scenario where a service request (client) uses a Signing Server to digitally sign a SOAP message. The Signing Server will authenticate the credentials (usually user id and password, as in step 1) against the client access profile. The client has just made a business transaction from the online shopping Web site. The business data is encapsulated in a SOAP message using JAX (step 2). Upon successful authentication, the signing applet will retrieve the key pairs from a secure database to generate a digital signature for the transaction (step 3) and transmit the transaction with the digital signature (say, in SOAP messages with a digital signature, as in step 4) to the application Service Provider. Figure 7-24. Server-Side Signing Model This design addresses the challenge of a massive PKI security implementation and the associated implementation cost. For example, Internet banking for retail banking services would require tens of thousands of digital certificates to be deployed first. This is a considerable implementation effort with complicated digital certificate management processes and operations. Without the PKI infrastructure, consumers cannot pay their online shopping with their digital signature (generated from their digital certificate). For small and medium- sized financial institutions, PKI implementation would not be pragmatic, in the context of financial risks, implementation risks, and total cost of ownership. Many online payments via wireless devices utilized the Signing Server design in the early days. For example, most phone handsets do not support a smart card device or cannot store a digital certificate. The Signing Server stores the unique identifier of the phone handset (which is unique for each phone set) and authenticates the user with a valid user id and password. Thus, the Signing Server design would be a good alternative. Another consideration is that client-side digital-signature generation requires the client browser to install Java Virtual Machine (JVM) version 1.3 or higher. Today's client browsers are configured with JVM version 1.2.x. Users need to install JVM 1.3 or higher manually from Sun's Web site (file size is about 5MB for JRE 1.3 and 12MB for JRE 1.4). If the client browser does not support JVM 1.3 or higher, the client browser session needs to download Java classes (which are jar files of at least 800KB size) in order to sign the transactions at run time. This may take two minutes on a Pentium II 300MHz PC. Alternatively, developers can use some digital signature tools (such as Baltimore's Keytools) that have a lightweight browser plug-in for generating signatures (the Java classes are about 300MB size, which can reduce the signing time to less than a minute). In summary, client-side generation of digital signatures is conceptually the ideal approach to implementing end-to-end Web Services security. This requires the local client to install a digital certificate and to download a signing applet (JCE/JAAS). The approach is good for customers with PKI infrastructure implemented and for high-value financial transactions. The implementation issue is that most browsers support JVM 1.2.2 or lower, and thus clients either upgrade to JVM 1.3 manually or download a signing applet at run time. The signing applet may have 700KB Java class size. Thus, it has longer response time for the signing. There are also cost and implementation considerations of distributing and administering digital certificates. Server-side generation of digital signatures denotes an intermediary server generating signatures on behalf of the end users. Certificates will be stored centrally on behalf of customers. A user id and password are used to authenticate the right user before retrieving the corresponding digital certificate for signature generation. This approach is good for mass-market implementation with low-value or zero-value financial transactions. This Signing Server approach does not require each end-user to own and install a digital certificate on its desktop. This raises another security issue ”there is a security and liability concern and potentially a legal implication for the intermediary Signing Server. The intermediate server may be vulnerable to hacker or virus attack. XML Encryption and XML SignatureThe current J2SE version 1.4 has provided some building blocks ( http://java.sun.com/security/ ) that provide encryption and digital signing functionality ”for instance, Java Authentication and Authorization Service (JAAS), Java Cryptography Extension (JCE), and Java Secure Socket Extension (JSSE). On top of that, JSR 183 Web Services message security API ( http://jcp.org/en/jsr/detail?id=183 ) is a proposed Java Specification Request to incorporate Java APIs to support WS-Security, including XML Encryption and XML Signature. Before JSR 183 is accepted and implemented in J2SE, several vendor products have now provided a vendor-specific reference implementation (such as Apache Axis and IBM XML Security Suite) for encrypting and signing SOAP messages. For instance, IBM's XML Security Suite ( http://www.alphaworks.ibm.com/aw.nsf/download/xmlsecuritysuite ) has some sample source codes found in its binary distribution under /xss4j/samples/enc and /xss4j/samples/dsig. Buy Versus BuildMost Web Services security tools are publicly available as a download or integrated with application servers. These tools are targeted for the developer audience. Thus, it is much easier to "buy" the tools versus write them from scratch. Although the security specifications evolve quickly, it is often beneficial and strategic to build some small prototypes yourself to get up to date with the technology so that you can understand more about the design and implementation considerations. |
/axis/wsdd/providers/java"> <handler name="log" type="java:org.apache.axis.handlers.LogHandler"/> <handler name="signer" 
- Challenging the Unpredictable: Changeable Order Management Systems
- Context Management of ERP Processes in Virtual Communities
- Distributed Data Warehouse for Geo-spatial Services
- Data Mining for Business Process Reengineering
- Relevance and Micro-Relevance for the Professional as Determinants of IT-Diffusion and IT-Use in Healthcare