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:

Monday Feb 04, 2008

Issuing SAML token of Bearer type

We add the support of issuing SAML assertions of bearer type where there is no proof keys associated
with the assertions. Before that, we only support issuing SAML assertions of AsymmetricKey or SymmetricKey proof key types.

For a service, IssuedToken of Bearer key type should only be used as a SignedSupportingTokens or SupportingToken, since it has no keys associated for encryption or signing purpose. We don't have Netbeans support for this use case yet but one may manually enable it. Here is the steps:

1. Create a service secured using IssuedToken as a supporting token:

2. Changed the EndorsingSupportedTokens to SignedSupportingTokens.

3. Changed the value of the KeyType element in the RequestSecurityTokenTemplate to

1) ws-sx version:

2) previous version:

No manual change required on the STS and client side.

Bearer key type is also used by the Windows Cardspace as default with a thin client fro Browser based Web site.

Sunday Feb 03, 2008

Support for OASIS WS-SX standards in Metro

We provide support for OASIS WS-SX standards WS-SecurityPolicy 1.2, WS-SecureConversation 1.3 and WS-Trust 1.3 in the current build of Metro. This will be included in the up-coming Metro 1.2 release as EA features. No Netbeans tooling support is avialbale yet. However one can manually modify the wsdl and configuration produced from Netbeans to produce WS-SX based service and STS. This applies to all the existing security scenarios using previous versions of WS-Trust and WS-SecureConversation.

1. Create a service secured with WS-SX:

First create a service with Netbeans using an IssuedToken from an STS and/or secure conversation for the security.
Then make the following the changes for the service WSDL:

1) Change the all the occurence of WS-SecurityPolicy namespace from
The change must also apply to the IncludeToken attribute.
2) Change all the occurence of the WS-Trust namespace from
This mainly applies to the element in the RequestSecurityTokenTemplate in
IssuedToken policy assertion and what used for Action.

3) Change the policy assertion Trust10 to Trust13.

2. Create STS of WS-SX version:

First Create an STS using Netbeans. (See also my blog entry for creating an customer STS). Then follow the above steps 1), 2) and 3)
to make the namespaces and policy assertion changes.

3. Using WS-Policy 1.5 with WS-SX:

With the service and STS produced from 1 and 2, WS-Policy 1.2 is used.
One may also use the standard WS-Policy 1.5 from W3C with WS-SX support.

For this,

1)Change all the occurence of the WS-Policy namespace from

2) Using addressing metadata:
Remove the policy assertion UsingAddressing.
And then add the following assertion instead to enable Addressing:
<wsam:AnonymousResponses />
Alos change the prefix for Action to wsam (e.g wsam:Action="").

This mainly address the use of WS-SX for existing features. There are also some new features introduced for Metro 1.2 which will be described in the subsequent blogs.
We will also provide samples with WS-SX in the current WSIT workspace.

Wednesday Nov 14, 2007

Web Services Interoperability Plugfest

We participated the latest Web Services Interoperability Plugfest hosted in Microsoft last week. Harold has a detailed report of the testing result in his blog.

This is the fourth time I have been to Redmond for the Plugfests. I was focused on the WS-SX scenarios this time. WS-SX covers Oasis standard versions of
WS-Trust1.3, WS-SecureConversation1.3 and WS-SecurityPolicy1.2. W3C standards WS-Policy 1.5 as well as WS-Addressing 1.0 are also used in the tests.

The testing scenarios are rather comprehensive which conver various combinations of the following:


1. TransportBinding where SSL is used to protect the messages.

2. SymmetricBinding with X509Token of the server

3. AsymmetricBinding with X509Tokens of the client and the server

Client Authentication Token:

1. Usernam/Password

2. X509 certificate

Issued Tokens from STS:

1. Token Type: SAML 1.1

2. Proof Key Type:

2.1 Symmetric Key

2.2 Public Key with Client X509 certificate

2.3 Optionally Public Key with ephemeral RSA key pairs from the client

2.4 No proof key with Bearer key type

Bootstrap client authentication token for Secure Conversation:

1. X509 certificate
2. Issued Token from an STS

For secure conversation, we tested both the issuance and the cancellation bindings.

As reported by Harold, we have successfully passed most of the testing scenarios.
The only remaining issue is that we have not completed the support of KeyValueToken for use with issued token of public proof key type with ephemeral RSA key pairs.

Sunday Oct 28, 2007

Metro and Netbeans for secure conversation

WS-SecureConversation introduces a handshake process which allows the
client and the service to authenticate to each other and to establish
a shared security context at the begining. This context contains a shared
secret key that can be used to secure the subsequent messages. This significantly
impoves the performance with multiple messages.

With WSIT and Netbeans, it is easy to enable secure conversation for your applications. Among 11 Netbeans WSIT security profiles (WSIT tutorial, chapter 6) defined, secure conversation can be enabled for the following ones:

Username Authentication with Symmetric Keys
Mutual Certificates Security
Message Authentication over SSL
Endorsing Certificate
SAML Sender Vouches with Certificates
SAML Holder of Key
STS Issued Token
STS Issued Token with Service Certificate
STS Issued Endorsing Token

To ensable secure conversation with any of the above mechanisms:
once you get here with Netbeans to configure the security mechanism (See
WSIT tutorial for more details),

click the "Configure" button:

Check the "Establish secure session (secure conversation)".
Then secure conversation is enabled for this project and the security mechanism configured is used in the boot strap (handshake)process for establishing the secure session.

In general if you want to secure your Web services with more than one message to send in the transaction, you should enable secure conversation.


Jiandong Guo-Oracle


« June 2016