Metro 1.0 Security Overview and What's coming Next

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   href="https://glassfish.dev.java.net/">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 ( href="https://wsit.dev.java.net/issues/show_bug.cgi?id=687">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 :

• href="http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf">WS-Security
  Core Specification 1.1
• href="http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf">Username
  Token Profile 1.1
• href="http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf">X.509
  Token Profile 1.1

href="http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf">

• href="http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf">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. href="http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf">
http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf



 Support for the recently approved  OASIS Standard version
of  Security Policy  href="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.html">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 href="https://wsit-docs.dev.java.net/releases/m6/index.html">Tutorial
and Samples.  Instructions on using NetBeans with GlassFish and
Metro are available href="https://wsit-docs.dev.java.net/releases/m6/install.html">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 href="https://metro.dev.java.net/discover/screencasts.html">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. href="https://xwss.dev.java.net/articles/security_config.html">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  href="http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf">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 :

1. Support for the recently approved  OASIS Standard version
   of  Security Policy  href="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.html">http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.html
   
   
2. Support for Password Derived Keys
3. 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
4. Support for Securing Attachments as defined by href="http://www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf">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.
5. 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 :

1.  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)
2. 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)
3. 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
4. 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.
5. 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.