Aug 05

This document discusses how the SOAP/HTTP Binding Component can be configured, in a service provider and in a service consumer, to use WS-Security 1.0 (2004) Username Token Profile support. WS-Security 1.0 (2004) provided support for the Username Token, which could be sent over the wire in the clear. This was insecure but Sun JAX-RPC libraries allowed this, since the standard allowed this. Through Project Metro release 1.4 it was impossibly to formulate a WS-Security policy that decorated a SOAP message with the Username Token headers, without requiring to also encrypt parts of the message. This prevented solutions built on top Metro 1.4, or earlier, from supporting cleartext Username Token. Metro 1.5 relaxed this requirement. The WS-Security policy configured using the GlassFish ESB NetBeans WS-Security wizard will be modified to require and provide a Plain text Username Token.

The document is here: 02_Configuring_HTTP_BC_for_WS-Security_UsernameToken.pdf

The companion archive containing all projects is here: WSSecPolicies_PersonUsernamePlain.zip

May 14

A couple of years ago I worked out how to supplement WS-Security infrastructure in Java CAPS 5.1.1 with additional services that WS-Security 1.0 (2004) supports, namely SOAP Message Security, X.509 Certificate Token Profile and Timestamp Token Profile. Together these provide Java CAPS solutions with XML Digital Signatures, XML Encryption, Sun Access Manager-mediated Username-based authentication and Timestamp support.

The attached document is 1 and a half years old. It makes statements about Username Token support in Java CAPS 5.1.1 being broken. Java CAPS 5.1.3 supports Username Token just fine so these statements are no longer true. Java CAPS 5.1.3 U2 adds a mechanism for hooking SOAP envelope handlers into the Java CAPS Web Services framework so what I did and described in the document can now be done differently – perhaps better and more transparently. I have not tried.

This material is provided on request on “all care but no responsibility” basis. Sun Java CAPS Support will not support this and neither will I. JAC-RPC from WSDP 2.0, which is at the heart of the implementation, is deprecated and has long since been replaced by WSIT/JAC-WS/Tango. Still, here it is if anyone is interested.

JCAPS with JWSDP 2.0, Implementing WS-Security_1.1_JCAPS5.1.1.pdf” – discussion paper

Supporting materials are over 40Mb so I can’t post them to the blog. If anyone is interested says so.

Well, someone said so. The archive, WSSecSampleProject_1.2_JCAPS5.1.1.zip, is posted. Please understand that this is “all care and no responsibility” material. I don’t have the time to spend working through issues with individual people. It all worked at the time I put it together and on occasions since. It ought to work for you as well 🙂

Oct 17

As at release 5.1 Java CAPS supports WS-Security 1.0 (2004) Username Token Profile. Java CAPS eInsight- and Java Collaboration-exposed web services can be configured to require and validate Username/Password credentials before performing their programmed function. Java CAPS eInsight-based and Java Colaboration-based web service consumers can be configured to supply WS-Security 1.0 (2004) Username Token SOAP Header.

Java CAPS 5.1.3_Notes_Using_WS-Security_1.0_Username_Token_Profile.pdf discusses configuration of the Username Token, creation of users, configuration of access to service and testing secured services. It illustrates the discussion with a step-by-step example of implementing, securing and exercising a web service consumer and a web service implementation which use the Username Token infrastructure.

WSDLWSUserAuth.wsdl is the WSDL interface specification document for a service developed in the example.

XSDWSUserAuthString.xsd is the XML Schema Document defining the data structure used as input and output of the example service.

FieldNotes_WSUsernameTokenProjectExports.zip is the Java CAPS 5.1.3 project export of the projects discussed in the document.


Tagged with:
preload preload preload