Kumar Jayanti's Blog

Accessing the SAML Assertion in the WebService

A Question that is often asked is, I am Using a WSIT Secure Scenario containing SAML Assertion, How do i access the SAML Assertion ?

Here is how you can access the SAML Assertion inside your WebService Endpoint Implementation Class. Note the method getSAMLAssertion() in particular.

package test;



import com.sun.xml.wss.SubjectAccessor;

import com.sun.xml.wss.XWSSecurityException;

import com.sun.xml.wss.impl.XWSSecurityRuntimeException;

import com.sun.xml.wss.saml.util.SAMLUtil;

import java.util.Set;

import javax.annotation.Resource;

import javax.jws.WebMethod;

import javax.jws.WebParam;

import javax.jws.WebService;

import javax.security.auth.Subject;

import javax.xml.stream.XMLStreamException;

import org.w3c.dom.Node;

import javax.xml.stream.XMLStreamReader;

import javax.xml.transform.Transformer;

import javax.xml.transform.TransformerException;

import javax.xml.transform.TransformerFactory;

import javax.xml.transform.dom.DOMSource;

import javax.xml.transform.stream.StreamResult;

import javax.xml.ws.WebServiceContext;

import org.w3c.dom.Element;



@WebService()

public class NewWebService {



    @Resource

    private WebServiceContext context;



    @WebMethod(operationName = "operation")

    public String operation(

            

           
@WebParam(name = "parameter") String parameter) {

        System.out.println("Hello "
+ parameter);

        //get the Assertion from the
Context

        Element samlAssertion =
getSAMLAssertion(context);

        //dump the assertion to
STDOUT

        try {

           
dumpDomNode(samlAssertion);

        } catch (
TransformerException ex) {

           
System.out.println("Error Dumping SAML Assertion");

        }

        return "Hello " + parameter;

    }



    private static Element
getSAMLAssertion(WebServiceContext context) {

        try {

           
Subject subj = SubjectAccessor.getRequesterSubject(context);

           
Set set = subj.getPublicCredentials();

           
Element samlAssertion = null;

            for
(Object obj : set) {

               
if (obj instanceof XMLStreamReader) {

                   
XMLStreamReader reader = (XMLStreamReader) obj;

                   
//To create a DOM Element representing the Assertion :

                   
samlAssertion = SAMLUtil.createSAMLAssertion(reader);

                   
return samlAssertion;

               
}

            }

        } catch (XMLStreamException
ex) {

           
//TODO:Add custom error handling logic

           
throw new XWSSecurityRuntimeException(ex);

        } catch
(XWSSecurityException ex) {

           
//TODO:Add custom error handling logic

           
throw new XWSSecurityRuntimeException(ex);

        }

        return null;

    }



    private static void dumpDomNode(Node node) throws
TransformerException {

        System.out.println("====
DebugUtil.dumpDomNode(...) Start ====");

        DOMSource domSource = new
DOMSource(node);

        TransformerFactory tf =
TransformerFactory.newInstance();

        Transformer xform = null;

        xform = tf.newTransformer();

        xform.transform(domSource,
new StreamResult(System.out));

        System.out.println();

        System.out.println("====
DebugUtil.dumpDomNode(...) End ====");

    }

}

Securing Metro WebServices Using Kerberos Tokens

My Colleague Ashutosh has posted a nice blog on how to secure Metro WebServices using Kerberos Tokens.

http://blogs.sun.com/ashutosh/entry/running_kerberos_token_profile_scenario

Support for Kerberos Token Profile would be available in Metro 1.1 release (to be out soon). If you want to try it right away then you can do so by downloading the latest nigtly here.

The Metro Kerberos Implementation was tested for interoperability with .NET implementation last month.

SSL and CRL Checking with GlassFish V2

Introduction

This blog is dedicated to some of the less documented but important aspects of using SSL on GlassFish V2. The following topics would be covered :

How to change the Keystore Password
Steps to develop a Skeletal Web Application that uses SSL Mutual Authentication
How to Enable CRL based Revocation Checking (Static CRL file approach)
How to Enable CRL based Revocation Checking (Dynamic approach)
Revocation Checking using OCSP (Online Certificate Status Protocol)

How to change the Keystore Password

We should not change the GlassFish Keystore password directly using Keytool, because if we did that then GlassFish would not know how to retrieve the keys from it anymore. The reason why one would want to change the keystore password is because the default password "changeit" is not a secure password (everyone knows it).

So what would happen if we change the keystore password directly using the following command :

>keytool -storepasswd -keystore keystore.jks -new newpassword -storepass changeit

Now when you start GlassFish it wouldn't know what the new password is so you would see the following exception

Caused by: java.lang.IllegalStateException: Keystore was tampered with, or password was incorrect
        at com.sun.enterprise.security.SecuritySupportImpl.loadStores(SecuritySupportImpl.java:114)
        at com.sun.enterprise.security.SecuritySupportImpl.initJKS(SecuritySupportImpl.java:82)
        at com.sun.enterprise.security.SecuritySupportImpl.(SecuritySupportImpl.java:76)
        at com.sun.enterprise.security.SecuritySupportImpl.(SecuritySupportImpl.java:71)

And GlassFish would Fail to start. So how does one change the Keystore password for GlassFish. When we see the GlassFish Admin Console we see the option to change the Administrator Password.

Application Server --> Administrator Password

Changing this password also does not help, because it changes the administrator password. So the real password to be changed is the GlassFish Master Password.

>asadmin stop-domain

Stop the domain if it is running, and then we can change the master password.

>asadmin change-master-password --savemasterpassword=true
Please enter the new master password>
Please enter the new master password again>
Master password changed for domain domain1

Now let us see what happens if we try to list the GlassFish Keystore using the old password

>keytool -list -keystore keystore.jks -storepass changeit
keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

So we see that it fails, now let us try with the changed masterpassword

>keytool -list -keystore keystore.jks -storepass newpassword

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entries

s1as, Nov 11, 2007, keyEntry,
Certificate fingerprint (MD5): C0:41:05:12:5A:77:E8:5D:1F:DB:FD:EF:E4:23:E2:42

This confirms that the right way to change the keystore password is to change the master password. Also do not forget the --savemasterpassword=true option when changing the masterpassword if you wish to save the changed masterpassword. Without this option the masterpassword file if it exists will be deleted and hence you will be prompted for the masterpassword every time you try to start the domain. On the otherhand be aware that there is a risk associated in saving the master passsword in a file

Another Caveat When Changing Master Password

If you have added more keyentries into the GlassFish Keystore other than the default "s1as" then when you change the master password, you will have to manually change the KeyPassword of the KeyEntries that you have added into the GlassFish Keystore. Otherwise GlassFish would again fail to start and you may see the following exception :

java.lang.reflect.InvocationTargetException
...........

Caused by: java.lang.IllegalStateException: java.security.UnrecoverableKeyExcept
ion: Cannot recover key
        at com.sun.enterprise.security.SSLUtils.(SSLUtils.java:128)
        ... 10 more
Caused by: java.security.UnrecoverableKeyException: Cannot recover key
        at sun.security.provider.KeyProtector.recover(KeyProtector.java:301)
        at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:120
)
        at java.security.KeyStore.getKey(KeyStore.java:731)
        at com.sun.net.ssl.internal.ssl.SunX509KeyManagerImpl.(SunX509KeyM
anagerImpl.java:111)
        at com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl$SunX509.engineInit

Assuming my GlassFish Keystore had a KeyEntry "myserver" in addition to "s1as" then upon changing the master password i would need to run the following command to change the keypassword for "myserver" to be the same as the new master password

>keytool -keypasswd -alias myserver -keystore keystore.jks -storepass

This comes from the limitation of the JSSE API. The keypassword and the keystore password cannot be different. The authentication process will fail if the keystore and the certificate's private key password are not the same.

Steps to develop a Skeletal Web Application that uses SSL Mutual Authentication

Assuming you are all set with your correct Server Certificates in place, here are the steps to create a Skeletal WebApplication that makes use of SSL Mutual Authentication. I made of NetBeans when developing the Application because it provides Visual Editing of the Security Settings described in this section and makes things very easy.

The WebApplication demonstrated in this section would just have a Welcome JSP and a Secure Hello.html page which is Secured by specifying a Security Constraint requiring SSL Mutual Authentication. You can access the complete WAR file for the Application here.

So here is the simple Welcome JSP page.

<%@page contentType="text/html"%>
......



           JSP Page



           Welcome to the SSL Mutual Authentication Test Page

Request a secure page here!

It will use SSL Mutual Authentication

In the web.xml we will add a Security Constraint for the URL pattern "/secure/*" which is where our Secure Hello.html page is located. We add a user-data-constraint with transport-guarantee CONFIDENTIAL indicating the need to use SSL. Then we add a login-config element with auth-method CLIENT-CERT to indicate the need for Client Certificate Authentication (making it an SSL Mutual Authentication Scenario).

In addition we would need to define the role which will be allowed to access the secure resources. Followed by a mapping of the role to groups/principals in sun-web.xml. Here is how the security portion of web.xml would look

Constraint1

secure resource

/secure/*

GET

POST

HEAD

PUT

OPTIONS

TRACE

DELETE

authorized

CONFIDENTIAL

CLIENT-CERT

authorized

And here is how the role mapping in sun-web.xml is defined as

authorized

Now the last thing we would need to do is add the assign-groups property for the Certificate Realm in Glassfish Domain.xml. This would make sure that all Client's with Valid Client Certificates get assigned a group named "authorized". Here is how the Cerificate Realm configuration in GlassFish would look like

How to Enable CRL based Revocation Checking (Static CRL file approach)

Certificates may be revoked by a Certification Authority for Various reasons. The most common proposed method for distributing revocation information requires an issuing authority to publish a signed list of revoked certificates (called CRL, acronym for Certificate Revocation List). The reasons for revocation and a whole lot of other details and issues with Revocation can be found elsewhere on the world wide web. In this section of the blog we will discuss how one can use such a CRL file to enforce certificate revocation checking.

Ofcourse a Static CRL file is no good because the revocation lists issued by the Certificate Authority are bound to change overtime and so any site/server depending on such a CRL file will need to deal with issues of timely updates to the CRL file inorder to ensure robust revocation information. A complete discussion of this topic is out of the scope of this blog.

The GlassFish http-listener element supports a Property called "crlFile" whose value is a CRL file to be consulted during SSL client Authentication. This can be an absolute or relative file path. If relative it is resolved against the domain-dir. If the property is not specified then CRL checking is disabled.

For this blog i created a sample CA (Certificate Authority) and generated a Client Certificate signed by the CA. I later revoked the Client Certificate and the CA generated a CRL(crl.pem) file containing the revocation information. Here are the steps to simulate an SSL Client Authentication Failure using the revoked certificate.

1. Install the revoked ceritificate in your Browser as the Client Certificate
2. Copy the crl.pem file into domains/domain1/config/ directory
3. Specify the "crlFile" property in domain.xml under the http-listener meant for SSL (port 8181)

Notice that the Property should come below the ssl child element of http-listener.

4. Install the CA certificate in GlassFish Truststore cacerts.jks using Keytool, or using NSS tools if you are running in the enterprise profile.

Now run the SSL Mutual Authentication Sample and you will see that the Client Authentication Failed, the following Message can be seen in the GlassFish server Logs :

[#|2007-11-12T17:32:54.113+0530|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=17;_ThreadName=httpSSLWorkerThread-8181-0;|
httpSSLWorkerThread-8181-0, fatal error: 46: General SSLEngine problem
sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Certificate has been revoked, reason: unspecified|#]

How to Enable CRL based Revocation Checking (Dynamic approach)

In the previous section we discussed static CRL file approach to revocation checking. But the JSSE supports Http URL based Revocation Checking wherein the Revocation List will be dynamically downloaded from the Ceritificate Authority. Since the SSL implementation in GlassFish is essentially layered upon the JSSE support so this feature of Dynamic CRL based revocation checking is supported by GlassFish. The information about the revocation list URL is encoded inside the Ceritificate itself as Extension elements . For example i created a certificate using the Verisign Test CA and the certificate it issued to me contains the following extension elements :

#2: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
[accessMethod: 1.3.6.1.5.5.7.48.1
   accessLocation: URIName: http://ocsp.verisign.com, accessMethod: 1.3.6.1.5.5.7.48.2
   accessLocation: URIName: http://SVRSecure-aia.verisign.com/SVRTrial2005-aia.cer]
]
#3: ObjectId: 1.3.6.1.5.5.7.1.12 Criticality=false
#4: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
     [URIName: http://SVRSecure-crl.verisign.com/SVRTrial2005.crl]
]]

Notice the CRLDistributionPoints extension which specifies the URL of the dynamicall downloadable CRL file from the CA.

The tradeoff between a Static CRL File and a Dynamic CRL download would be that a Dynamic CRL would be more robust and correct but the size of the CRL file may impact the performance of the revocation checking logic.

In GlassFish the following two system properties (understood by the underlying JSSE implementation) can be specified as jvm-options in domain.xml to enable Dynamic CRL download based Revocation Checking.

-Dcom.sun.net.ssl.checkRevocation=true

-Dcom.sun.security.enableCRLDP=true

This is because the way in which GlassFish uses the JSSE API's causes these two options remain false by default.

This approach ofcourse makes an assumption that the Certificate being used contains a CRL DistributionPoint Extension element. Otherwise enabling this option may cause failure. You may also need to set the http.proxyHost and http.proxyPort properties for this approach to work correctly. If for some reason the CRL file could not be fetched from the specified URL at runtime you may see an exception in the server logs of the following form :

[#|2007-11-12T16:54:20.877+0530|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=20;_ThreadName=httpSSLWorkerThread-8181-1;|
httpSSLWorkerThread-8181-1, fatal error: 46: General SSLEngine problem
sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: revocation status check failed: no CRL found|#]

Make sure you do not mix the static approach mentioned in previous section with this one, because although the static approach may work even with certificates that do not contain a CRL DP extension, enabling the dynamic CRL checking will cause failures if the Client certificate does not contain a CRL DP Extension.

To debug issues with CertPath API in JDK you can set the following JVM Option in GlassFish domain.xml : -Djava.security.debug=certpath

When the dynamic CRL checking succeeds you can see debug prints of the following form after enabling certpath debugging using the above option.

certpath: CrlRevocationChecker.verifyRevocationStatus() ---checking revocation status...|#]
certpath: Checking CRLDPs for CN=ABC, OU=Terms of use at www.verisign.com/cps/testca (c)05, OU=Foo, O=BAR, L=BLR, ST=KN, C=IN|#]
certpath: Trying to fetch CRL from DP http://SVRSecure-crl.verisign.com/SVRTrial2005.crl|#]
certpath: Downloading new CRL...|#]
certpath: Returning 1 CRLs|#]
certpath: CrlRevocationChecker.verifyRevocationStatus() crls.size() = 1|#]
certpath: starting the final sweep...|#]
certpath: CrlRevocationChecker.verifyRevocationStatus cert SN: 92665084177020392276407153602684386406|#]
certpath: -checker5 validation succeeded|#]

Revocation Checking Using OCSP

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 2560 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI).

The JSSE in JDK 5 and Later releases supports OCSP based revocation checking. The following link describes some of the PKI Enhancements in Java SE 5
http://java.sun.com/j2se/1.5.0/docs/guide/security/pki-tiger.html.

To enable OCSP revocation Checking we need to set "ocsp.enable" propertyto true. This property may be set either statically in the Java runtime's $JAVA_HOME/jre/lib/security/java.security file, or dynamically using the java.security.Security.setProperty() method. Incase of GlassFish the Static Approach of setting inside java.security file is what would be possible. This is because GlassFish does not set this property by default.

The JSSE documentation indicates that one can possibly enable both OCSP and Dynamic CRL DP approaches. It says, OCSP checking works in conjunction with Certificate Revocation Lists (CRLs) during revocation checking. Below is a summary of the interaction of OCSP and CRLs. Failover to CRLs occurs only if an OCSP problem is encountered. Failover does not occur if the OCSP responder confirms either that the certificate has been revoked or that it has not been revoked.

PKIXParameters RevocationEnabled (default=true)	`ocsp.enabled` (default=false)	Behavior
true	true	Revocation checking using OCSP, failover to using CRLs
true	false	Revocation checking using CRLs only
false	true	No revocation checking
false	false	No revocation checking

For revocation checking based on OCSP to work the certificate would need to have the URL of an online certificate status protocol (OCSP) server in the Authority Info Access (AIA) extension of the certificate (as shown in the example below)

However the JSSE layer allows specifying a ocsp.responderURL property. By default, the location of the OCSP responder is determined implicitly from the certificate being validated. The property is used when the Authority Information Access extension (defined in RFC 3280) is absent from the certificate or when it requires overriding.

By enabling Certpath Debugging you should see the debugging info as shown below when you set the ocsp.enable property to true.

certpath: connecting to OCSP service at: http://ocsp.verisign.com|#]
certpath: OCSP response: Successful|#]
certpath: OCSP response type: basic|#]
certpath: OCSP Responder name: CN=VeriSign Trial Secure Server OCSP Responder, OU=Terms of use at www.verisign.com/cps/testca (c)05, OU="For Test Purposes Only. No assurances.", O="VeriSign, Inc.", C=US|#]
certpath: Verified signature of OCSP Responder|#]
certpath: Status of certificate (with serial number 92665084177020392276407153602684386406) is: Good|#]
certpath: -checker5 validation succeeded|#]
certpath: checking for unresolvedCritExts|#]
certpath:
cert1 validation succeeded.
certpath: Cert path validation succeeded. (PKIX validation algorithm)|#]

Addressing Version Mismatch

A question on which i often have to search for the answer since the number of different addressing related URL's floating around are just too many...

>The WSE SOAP message contains xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" and
>whereas the WSIT implementation searches for a {http://www.w3.org/2005/08/addressing}Action header

This should be easy to fix. In your NetBeans Project, You can open your wsit-*.xml (inside build/web/WEB-INF) of your WSIT service and then look for the assertion :

"http://www.w3.org/2006/05/addressing/wsdl"/>

and change it to look as follows :

"http://schemas.xmlsoap.org/ws/2004/08/addressing/policy"/>

build and deploy.

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 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.

WSIT Security Configuration demystified

Here is a link to an article that contains the first set of details on WSIT Security Configuration...

WSIT Security Configuration demystified

I will be adding more details to it in the comings days and update readers about it whenever that happens.

Here are some of the other blogs of the team members working on WSIT Security, Trust and SecureConversation that you might find useful/related...

http://blogs.sun.com/venu
http://blogs.sun.com/shyamrao/
http://blogs.sun.com/ashutosh/
http://blogs.sun.com/harsha
http://blogs.sun.com/trustjdg
http://blogs.sun.com/manveen/