Kumar Jayanti's Blog: September 2007 Archive

Posted by kumarjayanti on September 17, 2007 at 03:14 AM | Permalink | Comments (4)

Metro is a high-performance, extensible, easy-to-use web service stack. For those of you who have heard about WSIT (WebServices Interoperability Technology) or already using WSIT, Metro is Just a Renaming of the Entire WebServices Stack from Sun. The 1.0 FCS Release of Metro is going to be announced soon and so is the FCS release of GlassFish V2. GlassFish V2 Embeds the Metro 1.0 Stack within it thereby making WebServices functionality directly usable from GlassFish (without the need for any extra downloads or installations).

The Metro Stack also carries over the original Goal of WSIT which is to enable interoperability between the Java platform and Windows Communication Foundation (WCF). The Metro stack is also intended to be runnable on other J2EE Containers as well as TOMCAT. Issues relating to dependencies of a couple of Metro Components on Sun's JDK will be sorted out very soon (see issue 687) and this would be a big step towards making Metro a Ubiquitous WebService's Stack. The WebServices Security implementation in Metro is based on a Streaming Architecture thereby augmenting the High Performance claims of Metro Stack .

An overview of WebServices Security Support in Metro 1.0 and what would be the new features in upcoming releases is what the rest of this blog is dedicated to.

Overview of WebServices Security Support in Metro 1.0

Security in Metro 1.0 is based on the following security related Specifications and Standards :

SAML Token profile 1.1

The support for UsernameToken Profile 1.1 in Metro 1.0 is partial in the sense that Metro does not support Password Derived Keys. The support for this is slated for a Near future Milestone release of the Metro.   The support for X.509 Token Profile 1.1 in Metro 1.0 is also Partial in the sense that Metro 1.0 only supports the X509V3 Token Type. Some of the other token types such as #PKCS7 and #X509PKIPathV1 are not supported in this release of Metro.

The Security Requirements and Capabalities of a WebService in Metro are expressed using WS-SecurityPolicy. The use of Security-Policy is a big step towards achieving Interoperability between WebService Clients and WebServices which can potentially be running on WebServices Stacks from Different Vendors and Operating Systems and Containers. The underlying Wire Interoperability is achieved by the use of WS-Security standard, as well as a lot of other things such as WS-I, WS-I BSP etc.

The Version of the WS-SecurityPolicy specification draft that Metro 1.0 supports is the following :

   1. http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf

Support for the recently approved OASIS Standard version of Security Policy http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.html is under development and is slated for a future Milestone release of Metro.

The Programming Model when developing WebServices Applications with Metro is the same old JAXWS Programming Model and nothing new is required to be learned.

Adding Security and other Quality of Service features to the JAXWS Webservice is enabled Via Configuration. Part of the configuration for Securing Access to the WebService is to specify the Security-Policy of the WebService. While people can do this manually by hand it can be a tedious and error prone process. Moreover the set of possibilities of Security Policy configuration for a WebService using the WS-SecurityPolicy specification is just too huge and developers may get confused when trying to map Abstract Security Requirements of their Applications into a Policy Definition consisting of a few dozen policy assertions. Metro provides a simpilification here by defining a few set of important Security Scenarios (sometimes called Security Profiles) and allows the developer to select and Apply the Profile for his/her WebService.   The result of Applying a Security Profile to a WebService is that the SecurityPolicy of the WebService is automatically generated. The profiles also allow for some amount of configurability in terms of tokens to be used, whether or not to use SecureConversation Sessions, whether or not to derive new keys from existing ones for multi-message exchanges, Which message parts to sign and/or encrypt etc. More information on this can be accessed from the WSIT/Metro Tutorial and Samples. Instructions on using NetBeans with GlassFish and Metro are available here.

The Token assertions in WS-Security Policy are abstract and need to be bound to some real Tokens at runtime (such as a username/password or an X509Certificate stored somewhere in a Keystore etc). To facilitate this binding, Metro/WSIT defines a set of Proprietary Policy Assertions applicable to the Client and Server side WebService Configurations. Again the use of NetBeans and its WSIT Plugin will ensure that the required configuration is easily specified inside UI Screens. A set of ScreenCasts are also available for users to get more familiarty with this configuration process. The following article(s) details the complete set of Proprietary configuration assertions supported by Metro/WSIT Secuirty Module.

    1. https://xwss.dev.java.net/articles/security_config.html

In the past Metro Security has been constantly tested for Interoperability with Microsoft .NET (WCF) and Metro Security will continue to evolve in this direction providing first-class interoperabilty in future as well.

What are the New Features being Planned in Metro Security (Future Milestone Releases) ?

The most important New Feature in Metro Security to be released in the Near Future is the support for OASIS Kerberos Token Profile 1.1 and ensuring that this feature interoperates with Microsoft .Net WCF. Some of the other features planned for future Milestone releases in the order of importance are the following :

Support for the recently approved OASIS Standard version of Security Policy http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.html
Support for Password Derived Keys
Support for Caching of Nonces and Replay Detection as outlined in WSS specifications. This was supported in XWSS 2.0 but this support in Metro was disabled due to a lack of Policy Assertion in the Version of Security Policy currently being implemented by Metro 1.0
Support for Securing Attachments as defined by WSS SOAP With Attachements Profile 1.1.This was supported in XWSS 2.0 but this support in Metro was disabled due to lack of a Policy Assertion to express securing of Attachments. The latest approved standard of WS-SecurityPolicy defines assertions to express security (integrity and confidentiality) for Attachments.
Further Performance Optimizations in the Metro Streaming Security Implementation.

New NetBeans profiles corresponding to the new features added will be available in the future releases.In addition Many other new and interesting features are being planned in the Metro WS-SecureConversation and WS-Trust Support and users are requested to look out for blogs relating to them.

A few other features which are currently being implemented (and will be put out soon on the Main Trunk, downloadable from the latest Nightlies) based on requests on the WSIT/Metro fourms from our users are as listed below :

Ensuring that the Bootrstrap Credentials during a SecureConversation are available in the Requester Subject for Application requests (This is already available on the Main Trunk)
Support for a Utility Class/Method to create a DOM representation of SAMLAssertion given an Assertion as an XMLStreamReader (This is already available on the Main Trunk)
Support for some kind of a Post Validation Hook for Tokens, that would allow developers to do custom validation of Tokens. For example checking a particular extension attribute in an X509 Certificate
Option to delegate Token Validation to a BackEnd System (instead of Metro Stack doing it on itself). For example a particular user has asked for a facility whereby the Signature of a Signed SAMLAssertion can be verified by a backend system.
Ensuring that Programmatic Username/Password credentials set on a Client Stub are passed on to the Embedded STS Client in case of Scenarios using WS-Trust.

Powered by
Movable Type 3.01D

java.net RSS Feeds