Jiandong Guo

Token Caching and Sharing, Single Sign On Among Services II: token life time

We will talk about how to manage the life time of an issued token on the client side.

[Read More]

Posted at 08:32PM Aug 17, 2009 by jiandongg in Sun  |  Comments[0]

ActAs and Credential Delegation III: Common Issues

Many users have picked up this feature for their applications. Here we will
describe some common issues come up so far and solutions.

[Read More]

Posted at 01:26PM Aug 13, 2009 by jiandongg in Sun  |  Comments[0]

ActAs and Credential Delegation II: Secure Conversation with STS

To optimize the communication with STS in this case, one should enable secure conversation.

[Read More]

Posted at 10:51AM Aug 09, 2009 by jiandongg in Sun  |  Comments[0]

ActAs and Credential Delegation

We provide support for ActAs introduced in WS-Truts 1.4.

[Read More]

Posted at 12:29AM Jul 01, 2009 by jiandongg in Sun  |  Comments[2]

JavaOne 2009 technical session slides are available

Harold Carr and I gave a talk on Metro security in this year's JavaOne. The slides for our session is now available here.

Please send your feedback or requirements in this blog or Metro forum.

Posted at 03:54PM Jun 15, 2009 by jiandongg in Sun  |  Comments[0]

Metro in JavaOne 2009

There are several talks in JavaOne 2009 as well as talks in CommunityOne 2009 related to Metro.

[Read More]

Posted at 04:19PM May 27, 2009 by jiandongg in Sun  |  Comments[0]

Token Caching and Sharing, Single Sign On Among Services

We provide support for caching and sharing issued tokens from an STS among multiple
services in Metro 2.0.

[Read More]

Posted at 03:05PM Apr 29, 2009 by jiandongg in Sun  |  Comments[4]

Matro 1.5 is released

Metro 1.5 released with some critical enhancements added and bugs fixed in security.

[Read More]

Posted at 01:14PM Apr 22, 2009 by jiandongg in Sun  |  Comments[0]

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]

Posted at 12:31AM Apr 13, 2009 by jiandongg in Sun  |  Comments[13]

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]

Posted at 12:42PM Mar 30, 2009 by jiandongg in Sun  |  Comments[13]

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]

Posted at 10:31PM Mar 23, 2009 by jiandongg in Sun  |  Comments[13]

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.

Posted at 12:14PM Feb 27, 2009 by jiandongg in Sun  |  Comments[0]

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="http://schemas.sun.com/2006/03/wss/server"     

        callbackHandler="common.KeyStoreCallbackHandler" alias="wssip"/>

    <sc:TrustStore xmlns:sc="http://schemas.sun.com/2006/03/wss/server"  

        callbackHandler="common.TrustStoreCallbackHandler"/>

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

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.

Posted at 01:12PM Feb 26, 2009 by jiandongg in Sun  |  Comments[0]

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="http://schemas.sun.com/ws/2006/05/trust/server" 

          encryptIssuedKey="true" encryptIssuedToken="false">

        <tc:LifeTime>36000</tc:LifeTime>                                

        <tc:Contract>com.sun.xml.ws.security.trust.impl.WSTrustContractImpl</tc:Contract>

        <tc:Issuer>SunSTS</tc:Issuer>

        <tc:ServiceProviders>

            <tc:ServiceProvider endPoint="http://localhost:8080/jaxws-s5/simple" >

               <tc:CertAlias>bob</tc:CertAlias>

               <tc:TokenType>

                   http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1

               </tc:TokenType>

            </tc:ServiceProvider>

            <!-- more service providers -->

        </tc:ServiceProviders>

    </tc:STSConfiguration>

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.

Posted at 11:55AM Feb 24, 2009 by jiandongg in Sun  |  Comments[0]

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="http://www.w3.org/2005/08/addressing">...</Address>

        </Issuer>

        <sp:RequestSecurityTokenTemplate

                xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">

            <t:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</t:TokenType>

            <t:KeyType>http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey</t:KeyType>

            <t:KeySize>256</t:KeySize>

            <t:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity" 

                      xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity">

                  <ic:ClaimType Uri="http://.../ws/2005/05/identity/claims/givenname"/>

                  <ic:ClaimType Uri="http://.../ws/2005/05/identity/claims/surname" Optional="true" />

            </wst:Claims>

        </sp:RequestSecurityTokenTemplate>

    </sp:IssuedToken>

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