Sunday Apr 12, 2009

Preposition Poems

Preposition Poems

[Read More]

Handling Token and Key requirements at Run Time, Part III: select STS at run time

How to write your own configuration to select STS and set STS parameters at run time.

[Read More]

Monday Mar 30, 2009

Handling Token and Key requirements at Run Time, Part II: Claims, TokenType, etc

This is the second part of this series of blogs for handling token and key requirements at run Time. We will explain how to inject and manage Claims.

[Read More]

Monday Mar 23, 2009

Handling Token and Key Requirements at Run Time, Part I: Overview

This is the first part of this series of blog for handling
token and key requirements at run time. We provide an overview
of this new feature.

[Read More]

Friday Feb 27, 2009

Attributes for SAML 2.0 Assertions

Many users have reported that with Metro 1.4, the attributes from a custom STSAttributeProvider
are not included in the issued SAML 2.0 assertions:

SAML attributes and DisplayToken
Problems with SAML 2.0 and the STSAttributeProvider values
Workaround for SAML2.0 broken STS attribute provider?
With Metro STS, STSAttributeProvider values is not take in the issued SAML 2.0 asertions.

This is due to a bug in the DefaultSTSTokenProvider when the SAML 2.0 assertion is created.
This issue is now fixed for Metro 1.5. Nightly build for Metro 1.5 should be available next week.

Also with Metro, we provide a pluggable STSTokenProvider for which you can use to create
issued tokens yourself. This is particularly useful if you want:

1. Customize SAML assertions created and to be validated.
2. Support for issuing and validating other types of tokens.

A custom STSTokenProvider can be pluggin the same way as for a STSAttributeProvider.
See this blog entry Create custom STS with WSIT for more information.

Thursday Feb 26, 2009

Dynamic Key Stores Configuration and STS

With Metro security, one can manage service and user certificates and keys dynamically with Callback handlers for key store and trust store:

<sc:KeyStore xmlns:sc=""
callbackHandler="common.KeyStoreCallbackHandler" alias="wssip"/>
<sc:TrustStore xmlns:sc=""

Here KeyStoreCallbackHandler implements and handles
com.sun.xml.wss.impl.callback.KeyStoreCallback and com.sun.xml.wss.impl.callback.PrivateKeyCallback;
while TrustStoreCallbackHandler implements and handles

See Kumar's blog for more details.

This dynamic mechanism can also be used with an Metro based STS.
For STS, keys and certificates for STS and the trusted service providers are used not only for securing the messages, but also used in the STS layer to protect the issued tokens:

1. The certificate and private key of the STS need to be used to sign issued tokens.
2. Certificate of each registered service provider needs to be used to encrypt the proof key and/or the issued token itself for the targeted service provider.

Originally an issue was found to make it work on the STS part. It is now fixed and should be working fine.

Tuesday Feb 24, 2009

Managing multiple services with Metro based STS

Metro based STS can be used to secure multiple services. One need to register
a service provider to an STS before the issued tokens of the STS can be used for that service.

Each resgisted service comes up as a ServiceProvide in the STSConfiguration:

<tc:STSConfiguration xmlns:tc=""
encryptIssuedKey="true" encryptIssuedToken="false">
<tc:ServiceProvider endPoint="http://localhost:8080/jaxws-s5/simple" >
<!-- more service providers -->

At the minimum, you need to specify the endpoint as well as the cert alias for each service provider. At run time, the actual service is identified for each request RST from a client to the STS. The RST contains an AppliesTo element pointing to the endpoint of the targeted service. On the STS side, the certificate of the service is used to encrypt the issued tokens and proof keys for the service.

With Netbeans, one can add Service Providers to an STS through the configuration panel for STS:

1. Click Configure button besides Act as Secure Token Service (STS).
2. In the STS Configuration panel, click Add.
3. In the Select Service Provider panel, add information of the service provider. Note that you must
import the certificate of the service provider to the TrustStore of the STS.

We provide a default Service Provider with endpoint="default". This default setting, working with any service providers, is for testing purpose only. In a product, you must remove it and add all the service providers to be secured by the STS.

You may also implement STSConfigurationProvider with your own STSConfiguration and TrustSPMetada to configure STS and register service providers to a deployed STS at run time.

Handling Claims with Metro STS

In WS-SecurityPolicy, an IssuedToken policy assertion may carry an optional wst:Claims element,
to specify the actual claims required to access the service. Here is an example of IssuedToken policy assertions with Claims:

<sp:IssuedToken sp:IncludeToken="...">
<Issuer xmlns="...">
<Address xmlns="">...</Address>
<t:Claims Dialect=""
<ic:ClaimType Uri="http://.../ws/2005/05/identity/claims/givenname"/>
<ic:ClaimType Uri="http://.../ws/2005/05/identity/claims/surname" Optional="true" />

On the client side, the Claims, together with all the other elements in the RequestSecurityTokenTemplate,
is copied into the request message RST to the STS.

With Metro based STS, the Claims will then be available in the STSAttributeProvider, for use to build
the user attributes to be included in the issued SAML assertion.

In your implementation of the method,
getClaimedAttributes(Subject subject, String appliesTo, String tokenType, Claims claims),
one may parse the Claims to obtain the ClaimTypes with the following codes:

String dialect = cliams.getDialect();
List claimTypes = claims.getAny();
for (Object claimType : claimsTypes){
Element ctElement = (Element) claimType;
// parsing ctElement according to the dialect to get claim types

Once you parse the Claims, you may create the attributes accordingly. The attributes returned from the STSAttributeProvider is available in the STSTokenProvider through:
(Map<QName, List<String>>) ctx.getOtherProperties().get(IssuedTokenContext.CLAIMED_ATTRUBUTES);
for you to build into your issued SAML assertions.

Tuesday Dec 30, 2008

Parsing SAML Assertion with Metro SAML API

Originally in Metro/XWSS, we only provided API to create SAML assertions, but no API to parse them. That's why in all the SAML related samples, we had to use primitive DOM API to parse SAML assertions to obtain user information. Since Metro 1.4, we have enhanced the SAML API to add support for parsing the SAML assertions.

Here are some sample codes on how to get user identity and attributes from an SAML assertion using these new API.

import com.sun.xml.wss.saml.Assertion;
import com.sun.xml.wss.saml.AssertionUtil;
import com.sun.xml.wss.saml.\*;

1. Create Assertion from an DOM element:

Element samlEle;
Assertion assertion = AssertionUtil.fromElement(samlEle);

2. Get user attributes and Subject

Subject subject = null;
NameID nameID = null;

// SAML 2.0
try {
     subject = assertion.getSubject()};
}catch (Exception ex){
     subject = null;

if (subject != null){
     nameID = subject.getNameId();

List&lsaquo Object&rsaquo statements = assertion.getStatements();

for (Object s : statements){
     if (s instanceof AttributeStatement){
         List&lsaquo Attribute&rsaquo attrs = ((AttributeStatement)s).getAttributes();
         for (Attribue attr : attrs){
                 String attrName = attr.getName();
                 List&lsaquo Object&rsaquo attrValues = attr.getAttributes();
                 String attrValue = ((Element)attrValues.get(0)).getFirstChild().getNodeValue();

         // for SAML 1.0, 1.1
         if (subject == null){
                 subject = ((AttributeStatement)s).getSubject()
     } else if (s instanceof AuthenticationStatement){
         subject = ((AuthenticationStatement)s).getSubject();


3. Get the user identifier in the Subject:

if (nameID != null){
     //SAML 2.0 case
     String id = nameID.getValue();
     String nameQualifier = nameID.getNameQualifier();
     String format = nameID.getFormat();
     // SAML 1.0, 1.1. case
     NameIdentifier nameIdentifier = subject.getNameIdentifier();
     if (nameIdentifier != null){
         String id = nameIdentifier.getValue();
         String nameQualifier = nameIdentifier.getNameQualifier();
         String format = nameIdentifier.getFormat();

Saturday Dec 06, 2008

Metro Adoption

Metro adoption information.

[Read More]

Thursday Oct 30, 2008

Metro 1.4 is released

Metro 1.4 is released today.

Metro 1.4 release includes WSIT 1.4, JAX-WS RI 2.1.5 and JAXB RI 2.1.7.

You may find the release notes for each of the components linked above.

Other than a few new features listed in the release notes, there are many bug fixes in this release.
Many of these bugs /feature enhancement requirements were led from the discussions in Metro forum and filed by external users. This improves significantly the quality and usability of Metro.

Check out Metro site for more information:

You may also find some stories how Metro is used in the real world:




Wednesday Oct 15, 2008

New Article: Using WS-Trust Support in Metro to Secure Web Services

I just published a new tech tip:
Using WS-Trust Support in Metro to Secure Web Services

It focuses on how to use different types of proof keys associated with issued tokens from an STS to secure Web services.

Thursday Jul 03, 2008

New trust features in Metro 1.3

A new ws-trust sample is available in Metro, the Web services stack for Glassfish.
This sample illustrates some of the exciting new features and use cases introduced in Metro 1.3, including:

1. Use Issued Saml assertion with SAMLToken policy assertion to authenticate to the service. An independent STS call on the client side with IssuedTokenManager
is required in this case. This shows how to use STS in more general context going beyond the specific IssuedToken policy assertion pattern.

2. Use the WS-Trust validation binding to validate the issued SAML assertion with the STS on the service side.

With these new features, I believe more interesting applications can be built on top of Metro.

Here is a brief description of the message flows in the sample:

1. The client obtains the service WSDL with policy. The policy has a SAMLToken
assertion as a SignedSupportingToken indicating that a SAML assertion is required
to access the service.

2. The client makes a calls to the STS in its SamlCallbackHandler to request for an SAML assertion.

3. The client calls the service with the SAML assertion from the STS.

4. The service calls the STS to validate the SAML assertion in its SamlValidator.

Sunday Apr 06, 2008

JavaOne Talk

I will give a talk in 2008 JavaOne together with Symon Chang of BEA.

Here is the information.

Session Date/Time:

7:30 PM -8:20 PM

Session ID:


Session Title:

Java™ Technology for Web Services Secure Exchange: New WS-SX Standards in Action

Session Description:

WS-SecurityPolicy 1.2, WS-SecureConversation 1.3, and WS-Trust 1.3 are three new standards from the OASIS Web Services Secure Exchange (WS-SX) Technical Committee (TC). On top of OASIS WS-Security, these three new standards will enable developers on the Java™ platform to make enterprise Java technology-based web services applications more efficient and more secure in a large, distributed service-oriented architecture (SOA) environment.

This session delves into the Oasis WS-SX standards and discusses the web services security essentials for enterprise technology developers on the Java platform. It presents best practices for end-to-end interoperability and security scenarios and recommends the best strategy for deploying WS-Security together with WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. It provides guidance for how these technologies should be used in the real world.

The presentation also discusses issues of interoperability among different vendors on different platforms with these three security exchanges and makes recommendations on how to ensure interoperability with various web services security scenarios.

Attendees who have a basic knowledge of web services, SOA, and WS-\* standards and want to implement web services security will benefit the most from this session. The speakers are WS-SX TC members with expertise in the web services security arena. They are ready to answer any deep technical questions on fields related to Java platform and web services security.

Wednesday Feb 06, 2008

ws-sx sample in Metro

A sample for OASIS WS-SX standards based scenario is available now:
Check the readme for how to set up and run the sample:


Jiandong Guo


« March 2015