« July 2009
SunMonTueWedThuFriSat
   
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today

Blog::Navigation

Blog::Editing

Bookmarks::Blogroll

Blog::Referrers

Today's Page Hits: 189

Site notes

This page validates as XHTML 1.0, and will look much better in a browser that supports web standards, but it is accessible to any browser or Internet device. It was created using techniques detailed at glish.com/css/.

Powered by Roller Weblogger.
Main | Next page »
Wednesday Jul 01, 2009

ActAs and Credential Delegation

We provide support for ActAs introduced in WS-Truts 1.4 with the latest Metro 2.0 nightly build.

Check out this interesting sample on how ActAs can be used for credential delegation in the case
that the user need to access a chain of services. Here is a detailed description of the scenario
for the sample.

Monday Jun 15, 2009

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.

Wednesday May 27, 2009

Metro in JavaOne 2009

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

[Read More]

Wednesday Apr 29, 2009

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]

Wednesday Apr 22, 2009

Matro 1.5 is released

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

[Read More]

Monday Apr 13, 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="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.

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

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 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();
}else{
     // 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 is a high-performance, extensible, easy-to-use web service stack. It is a part of the GlassFish offerings, but it can be also used outside GlassFish. Metro is also integrated into OpenSSO for an Security Token Service (STS), and OpenESB for SOAP and security handling.

In the past year or so, the adoption of Metro is in surge. Here is a list of some of the endorsements of Metro as in http://blogs.sun.com/stories/:

1. Apologic
"JPA (Toplink Essentials) and JAX-WS (Metro) are the key server-side technologies used by Apologic"

2. Advantech
"In one particular project we used both OpenESB and Tomcat+Axis2 (on separate machines), where project Metro (WSIT compliance) was a major factor to the success."

3. Selmet
"We have done some performance and stability testing and found that response time was quite impressive, better than IIS 6.0. One simple observation, when you first call a Web Service instance running on IIS is a lag lasting a few seconds which. On the terminal side, this lag using GlassFish is almost invisible to users. We were very pleased with the result but also with the monitoring features for Web Services which are really helpful."

4. FAA's NASE
"Setting up JDBC resources, Web Services, and HTTP Services are smooth as a glassfish."

5. Reino
"We decided to use JEE5 based technologies - JSF, JAX-WS and JPA - and the only complete application server which was capable of supporting these technologies at the time was Glassfish."

6. Fraunhofer Gesellschaft
"Yes, we investigated several open source web service frameworks, e.g. Apache Axis 2 and JBoss Web Services. The choice to use WSIT is based on the promoted interoperability with Microsoft platforms."

7. Carrefour
"The architecture uses GlassFish's Metro to expose a BAPI (SAP's most used API) as a Web Service. As of this writing, the architecture in production relies on the latest and greatest 9.1 ur1 release which integrates Metro 1.1. NetBeans was used as the IDE to develop the entire code in a record time."

8. Okair
"We use Web Services for access to timetables and information about actual traffic from the airport web server."

9. Numera

" We mainly use Web Services (Metro) to communicate with .Net."

10. Imixs
"Specifically, Java Persistence (JPA), EJB 3.0, and Web Services API (JAX-WS) are the main new technologies used by Imixs."

11. Microsoft BizTalk
"As a result of this collaboration, Metro 1.2 is going to be a better and more interoperable release for the Sun's customers and the greater Java community and BizTalk Services as well as our future identity products will be better and more interoperable, too. Win-Win. Thank you, Sun."

With more than 10 posts in an average day, Metro forum is one of the most popular one among java.net forums . This is an indication of a large user base for Metro. The interests in Metro as shown up in the forum ranging from low level JAXB API to the most advanced features like WS-Trust based STS. Here is a forum thread where an user is uing Metro WS-Trust support to build Enterprise interoperable health care solution based on
Oasis XSPA (Cross-Enterprise Security and Privacy Authorization) WS-Trust Profile:
"I hate to be a bother on the forums, but we're doing exciting stuff with Metro for a big standards (e.g. OASIS) interoperability demo coming soon. Its great stuff so far."

A Bother? No. Exciting and great stuff? Yes, indeed.

Copyright (C) 2003, jiandongg