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]

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 21, 2007

Metro Security Resources

The following resources help you to understand the security features of Metro/WSIT and how to use those features to secure Web services in your applications.

1. This is a good overview of WSIT including security features by Arun:

2. WSIT tutorials contains how to use and configure various Web services security features with Netbeans:

3. Here is a white paper about WS-Trust (an advanced feature in Web services security) support in WSIT:

4. Check my blog with a summary of WSIT based Web service security samples:

5. Our JavaOne presentation give an overview of security features in WSIT:

6. This blog entry of Kumar gives a summary of WS-Security and WS-SecurityPolicy support in Metro 1.0 and the plan in the future. It also explains the Proprietary security configuration used.

Monday Sep 17, 2007

WS-Trust in WSIT 1.0

WSIT 1.0 is released today in line of the release of Glassfish V2. WS-Trust is supported in WSIT 1.0 as a major security feature.

Here is a summary of the WS-Trust support in WSIT:

1. Support for token issuance protocol
2. Support for Security Token Service (STS) Framework for building STS as a
independent Web service.
3. Client and Service Authentication and Security with issued tokens from STS
within the general framework of WS-Security and WS-SecurityPolicy.

More about STS support:

1. Provide a general framework for building STS as an Web service for issuing
security tokens.
2. Authentication and secure communication between client and STS handled in the
same way as for a regular Web service.
3. Support for issuing SAML1.0, SAML 1.1 and SAML2.0 tokens by default.
4. Support for issuing symmetric key and public key (partially)
5. Extensible to support for issuing other types of tokens
6. Allows for plugging-in authorization mechanisms for controlling the issuing of
the tokens according to the user's identity and the targeted service.
7. Allows for plugging-in user mappings for controlling the user
identity/attributes carried in the SAML token issued by STS for different services.

WS-SecureConversation in WSIT 1.0

WSIT 1.0 is released today in line of the release of Glassfish V2. WS-SecureConversation is supported in WSIT 1.0 as a major security feature. WS-SecureConversation, built on top of the general mechanisms
defined in WS-Security and WS-Trust, provides a way to establish security context (session) for more efficient communication and better security for multiple message exchanges between a cleint and a service.

Here is a summary of the WS-SecureConversation support in WSIT:

1. SCT Binding of WS-Trust (Issuance binding) for establishing security context
2. Embedded STS for issuing SCT - each WSIT enabled Web service can act as an STS for managing security context.
3. Security context concellation
4. Extensible SessionManager to persist security contexts for Web farms
5. Align with WS-RM to secure reliable messaging sessions.
6. SecurityContextToken for securing messages in the framework of WS-Security
7. Support for Key Derivation and KeyDerivedToken with various types of tokens.
8. Using Netbeans, enabling secure converation is just a click of a button on top of any security profiles.
9. Overall, performance improvement using secure conversation is significant, of 250 to 450 percent depending on the size of messages and the number of messages sent.


Jiandong Guo


« April 2014