Friday Feb 01, 2008

Kerberos token based WS Security Scenarios on Tomcat

My previous blog Running Kerberos Token Profile scenario with Metro showed how to run kerberos token based WS-Security scenarios on Glassfish. Here I show the small changes you need to do to run it on Tomcat. The steps essentially boil down to specifying the location of JAAS login config file where login modules for Kerberos are stored. Glassfish picks the login modules from $GLASSFISH_HOME/domains/domain1/config/login.conf, in Tomcat we need to specify the file explicitly using system property.

Here are the complete steps:

  1. Create a file jaas.conf , and place it in $CATALINA_HOME/conf. Here's what jaas.conf looks like:
            KerberosClient { 
       required useTicketCache=true; 
            KerberosServer { 
       required useKeyTab=true keyTab="/etc/krb5.keytab" doNotPrompt=true storeKey=true principal="websvc/service@INDIA.SUN.COM"; 
  2. Add following line to the script (or specify the mentioned JAVA_OPTS property):
            JAVA_OPTS="$JAVA_OPTS "$CATALINA_HOME/conf/jaas.conf
  3. Specify the following system property in your client code:${tomcat.home}/conf/catalina.policy${tomcat.home}/conf/jaas.conf

Thursday Dec 06, 2007

Running Kerberos Token Profile scenario with Metro

As promised in my previous blog, I have tried to put here steps to run a Kerberos Token Profile based WS Security scenario using Metro. Please note that the Kerberos support in Metro is still experimental, and we do not provide a Netbeans support for it yet. Consequently, one has to modify the xml configuration files produced through Netbeans manually to test Kerberos. Netbeans support for Kerberos will come with one of the future release of Metro.

Setting up Kerberos

  1. Install and setup Kerberos appropriate to your environment. The following blogs give good account on how to setup Kerberos for Solaris 10 and Ubuntu Linux:

Make sure DNS lookups (or whatever name service in /etc/resolv.conf) to the kdc are working correctly.

                     # nslookup [hostname]
                     # nslookup [ip address]
  1. Add user accounts for kerberos client and service to use

    • Create a user principal for your kerberos account. It is used to administer the kerberos account.

                     # kadmin.local -q "addprinc admin/admin"
                     [type password]
    • Add user accounts for kerberos client and service to use

                      #kadmin.local -p admin/admin
                       kadmin.local: addprinc -randkey -e "aes128-cts-hmac-sha1-96:normal" [service_principal]
                                     (Ex of service_principal: websvc/service)
                       kadmin.local: addprinc -e "aes128-cts-hmac-sha1-96:normal" [client_principal]
                       [type password]
                                    (Ex of client_principal: testClient)
                       kadmin.local: ktadd -e "aes128-cts-hmac-sha1-96:normal" [service_principal]
                       kadmin.local: quit
    • Login to your kerberos account just created.

                      #kinit [client_principal]
                       [type password] 

Setting up Glassfish and Metro to run Kerberos Scenario

        1. Specify the login modules to be used for Kerberos in <GLASSFISH_HOME>/domains/domain1/config/login.conf. Paste the following at the bottom of this file:

                KerberosClient { 
            required useTicketCache=true; 

                KerberosServer { 
            required useKeyTab=true keyTab="/etc/krb5.keytab" doNotPrompt=true storeKey=true principal="websvc/service@INDIA.SUN.LOCAL"; 

You can give any names to this login modules (instead of KerberosClient and KerberosServer). You will have to refer to these names from the <sc:KerberosConfig> assertion in the wsdl and wsit-client.xml files.

Also edit the principal in KerberosServer to the service_principal you created.

        2. Create a Secure JAX-WS application using Netbeans. Refer 'Using WSIT Security' chapter from WSIT tutorial. Use any Security mechanism e.g. Mutual Certificates Security. Open the <wsit-service-name>.xml file created and replace the Binding level policy with the following policy:

Note the element <sc:KerberosConfig xmlns:sc=""/> which points to the LoginModule to be used for the service.

        <wsp:Policy wsu:Id="IFinancialService_policy">
                <wsaws:UsingAddressing xmlns:wsaws=""/>
                                <sp:KerberosToken sp:IncludeToken="">
                                        <!--<sp:RequireDerivedKeys />-->
                <sc:KerberosConfig xmlns:sc="" loginModule="KerberosServer"/>

Deploy this service.

        3. Create a client to access this service using Netbeans. Refer to the WSIT tutorial as mentioned in point 2. Edit wsit-client.xml file created (or the file included in wsit-client.xml) and replace sc:KeyStore and sc:TrustStore elements with:

<sc:KerberosConfig wspp:visibility="private" loginModule="KerberosClient" servicePrincipal="websvc/service@INDIA.SUN.LOCAL"/>

Modify the loginModule to the one you created for client in login.conf file for the client and the servicePrincipal to the name of the service principal for which ticket needs to be obtained. If your client is a Java SE client, you need to set the following system properties while running your client code:${glassfish.home}/domains/domain1/config/server.policy${glassfish.home}/domains/domain1/config/login.conf

If it is WebApp deployed on glassfish, nothing else needs to be done. Deploy and run the client.

Updated on 9 Jan 2008

Kerberos support in Metro security now supports credential delegation from client to service, such that the server can initiate other security contexts on behalf of the client. This feature is useful for single sign-on in a multi-tier environment.

The way for client to ask for credentials delegation is to set the attribute credentialDelegation to true on KerberosConfig element in wsit-client.xml. For example:
<sc:KerberosConfig wspp:visibility="private" loginModule="KerberosClient" servicePrincipal="websvc/service@INDIA.SUN.LOCAL" credentialDelegation="true" />

At the service, we can obtain the delegated credentials from the Subject of the authenticated user. The PrivateCredential set of the will have the delegated client credentials (as GSSCredential). We can pass this GSSCredential to GSSManager.createContext() pretending to be the client.

Also, the PublicCredential set of the authenticated Subject will always have KerberosPrincipal corresponding to the client.

Friday Nov 16, 2007

Web Services Interoprability Plugfest and Kerberos Token support in Metro

Sun participated in the latest Web Services Interoperability Plugfest hosted by Microsoft at their Redmond campus from November 6th to 8th. Harold, Jiandong and myself represented Sun at this event. Harold has a put forward a detailed entry with the details on the scenarios we tested and the results. Jiandong explains the WS-SX tests and the versions of specs they cover in his blog.

My focus at this event was to test for the first time our implementation of Kerberos Token Profile 1.1 for interoperability with .NET 3.x. The most difficult part for Kerberos interoperability turned out to be setting up the Kerberos infrastructure for trust. Once we were through this part, all the tests passed without any difficulty. The tests consisted of the following scenarios:

Basic Kerberos token tests

Kerberos Token with Derived Keys

SecureConversation with Kerberos token in Bootstrap policy

SecureConversation with Kerberos token and Derived Keys in Bootstrap policy

All these scenarios are available at the public endpoint from Microsoft at . Harold has details on the exact tests and results in his blog.

These tests were run using a single KDC for WSIT client and WCF service and vice versa.

The Kerberos token support will release with a future release of Metro, but if you want to give it a try, you can get one of the nightlies from here. I plan to blog about setting up kerberos infrastructure and running kerberos scenarios in coming weeks.

The next step we want to try is to use different KDCs for client and service and test cross-domain security using Kerberos. We tried it this time and ran across some setup issues with DNS configurations and cross domain trust.




« June 2016

No bookmarks in folder