Building Kerberos-Based Secure Services Using Metro

by Ashutosh Shahi

Metro is a high performance, extensible, easy to use web service stack. It combines the JAX-WS reference implementation with Project Tango. Project Tango, also called Web Services Interoperability Technology or WSIT, implements numerous WS-\* standards to enable interoperability with other implementations and to provide Quality of Service (QOS) features such as security, reliability, and transaction support. Metro is bundled as part of Sun Java System Application Server 9.1. Metro also runs in other containers such as Tomcat.

The March 2007 Tech Tip, Securing Web Services Using WSIT, focused on WSIT's support for web services security and showed how to secure a web service using WSIT's features. It was followed by the October 2007 Tech Tip, Testing Interoperability Between Metro and .NET, which showed a sample that demonstrates interoperability between Metro and .NET. This Tech Tip builds on the March 2007 tip. It shows how to build secure web services and clients using the Kerberos support in Metro. Kerberos support has been added to the security support provided by WSIT for Metro 1.1. Future releases of Metro will continue to include this added support. The support for Kerberos security in WSIT is based on the WSS:Kerberos Token Profile 1.1 implementation. You request Kerberos security in Metro using WS-SecurityPolicy assertions -- these assertions are covered in the "Securing Web Services Using WSIT" tip.

A sample application package accompanies this tip. The code examples in the tip are taken from the source code of the sample (which is included in the package). The sample application is similar to the one used in the "Securing Web Services Using WSIT" tip. The major difference is that the WS-SecurityPolicy assertions in the sample application for this tip specify Kerberos tokens and consequently the messages are secured using the Kerberos V5 protocol.

Introduction to Kerberos

Kerberos is a network authentication service developed as part of Project Athena at the Massachusetts Institute of Technology. The protocol is named after Cerberus, known in Greek mythology as the three-headed monstrous dog who guards Hades.

Kerberos assumes that network connections, rather than servers, are the weak links in network security, and so interactions between hosts and clients should be encrypted. Kerberos uses a trusted third party, termed a Key Distribution Center (KDC), which consists of two separate logical parts: an Authentication Server (AS), and a Ticket Granting Server (TGS). The KDC maintains a database of secret keys. Each entity in the network, whether it's a client or a server, shares a secret key known only to itself and to the KDC. Knowledge of this key serves to prove an entity's identity.

For communication between two entities such as a client and a service, the KDC generates a session key which the entities can use to secure their interactions. Figure 1 shows the steps taken to secure a client's access to a service:

Securing Client Access to a Service Using Kerberos
Figure 1. Securing Client Access to a Service Using Kerberos
 
  1. A user enters a user name and password on the client. The client executes a one-way hash function on the password to generate a secret key for the user. The client sends a cleartext request to the AS to request a Ticket Granting Ticket (TGT). This TGT is later used by the client to request tickets for any specific service.
  2. The AS checks to see if the client is in its database. If the client is in the database, the AS generates a reply containing the following:
    • A session key encrypted with the secret key of the user. The encrypted session key is kept in secret between the client and the TGS.
    • A TGT encrypted using the secret key of the TGS.
  3. The client obtains the encrypted session key from the above message and decrypts it. This session key is used for further communication with the TGS. Note that the client cannot decrypt the TGT because the TGT is encrypted using the TGS's secret key. When the client requests access to services, it sends a message to the TGS composed of the following:
    • The TGT obtained in Step 2 and the ID of the requested service.
    • An authenticator that includes a client ID and timestamp.
    • The authenticator is encrypted using the client/TGS session key.
  4. When it receives the message from the client, the TGS decrypts the TGT using its secret key. This gives the TGS the client/TGS secret key. The TGS verifies the authenticator using this secret key. If the verification is successful, the TGS sends the following to the client:
    • A client-to-server ticket that includes the client ID, validity period, client/server session key, as well as other information. The client-to-server ticket is encrypted using the service's secret key.
    • The client/server session key encrypted with the client/TGS session key.
  5. The client decrypts the client/server session key, and now has enough information to authenticate itself to the service. The client sends the following to the service for authentication:
    • The encrypted client-to-server ticket.
    • A new authenticator that includes the client ID and timestamp. The new authenticator is encrypted using the client/server session key.
  6. The service decrypts the ticket using its own secret key and verifies the authenticator. If mutual authentication is not enabled (this is discussed later in this tip), the server is now ready to provide the requested services to the client. Also, communication between the client and the service can be secured using this client-to-server secret key.

Setting up Kerberos

This tip assumes that you have Kerberos set up in a UNIX environment. If you need information on how to set up Kerberos in the Solaris or Ubuntu Linux environments, see the following documents:

Note that in a Windows environment you can set up a Kerberos KDC only on Window Server editions 2000 and 2003. The KDC is bundled in these editions with its own Kerberos implementation called Active Directory. You cannot install the MIT Kerberos KDC on Windows. A Windows XP system can act as a client of the Windows Server 2003 KDC. Alternatively, you can install a client module of MIT Kerberos for Windows -- see Kerberos for Windows Release 3.2.2. You can then use the client module to authenticate against a KDC that was set up on a UNIX system.

After you set up Kerberos, make sure that the following DNS lookups to the KDC are working correctly.

   # nslookup [kdc_hostname]
   # nslookup [kdc_ip]

For example, you might enter the following command:

   nslookup ashu07.india.sun.local

In response, you should see the IP address of your system, such as 129.158.229.84. Similarly, if you enter the following command:

   nslookup 129.158.229.84

You should see the hostname of your KDC such as ashu07.india.sun.local. The idea here is that the DNS server is able to resolve the hostname of your KDC correctly.

Next, add user accounts for the client and service that will be used in this tip, as follows:

  • Create a user principal for your Kerberos account by entering the following command:
       # kadmin.local -q "addprinc admin/admin"
            [type password]
    
    The user principal is used to administer the Kerberos account.
  • Add user accounts for the Kerberos client and service by entering the following commands:
       #kadmin.local -p admin/admin
        kadmin.local: addprinc -randkey -e
        "es128-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 the Kerberos account that you created by entering the following command:
       #kinit [client_principal]
            [type password]
    

Kerberos Security With Metro and GlassFish

Metro 1.1 (and future releases) enables secure communication of SOAP messages between a client and a service using Kerberos V5 protocol. The Introduction to Kerberos section presented the steps in securing communication between a client and a service using Kerberos. Let's examine how those steps are performed using the Kerberos support in Metro.

  • Step 1 and 2: A user (that is, the client) logs into the pertinent account, for example using the kinit command, or the client obtains a new TGT.
  • Step 3: Before accessing a service, the client accesses the name of the service principal from a configuration file named wsit-client.xml used in Metro (the wsit-client.xml file is discussed later in the tip) and requests a ticket for the service principal from the KDC.
  • Step 4: If the client has valid credentials, the KDC grants the client a ticket for the service and a secret key to be used with the service.
  • Step 5: All the communication in the previous steps takes place outside of SOAP messages. However at this point communication is performed using SOAP messages. After the client has the ticket for the service and secret key, it sends the ticket and authenticator to the service enclosed in a BinarySecurityToken element in the SOAP Security header. The client also secures any protected information in the SOAP message using the secret key for this session.
  • Step 6: The service decrypts the ticket to obtain the session key and verifies the authenticator. If the authentication is successful, the service uses the secret key to verify the integrity or confidentiality of the protected parts of the message.

Creating a Kerberos Token-Based SecurityPolicy for the Service

To enable security for a web service with WSIT, you need to create and attach a security policy to the Web Services Definition Language (WSDL) file for the service. In general, there are two types of security policies you need to create for the web service: binding level policy and operational level policy. See the Securing Web Services Using WSIT tip for an explanation of these policies. The binding level policy shown in that tip needs to be changed to specify the use of Kerberos tokens. A Kerberos token here is the ticket and authenticator enclosed in the BinarySecurityToken element in the SOAP Security header as described in Step 5 above.

   <wsp:Policy wsu:Id="IFinancialService_policy">
   <wsp:ExactlyOne>
      <wsp:All>
          <wsaws:Us"http://www.w3.org/2006/05/addressing/wsdl"/>
          <sp:SymmetricBinding>
             <wsp:Policy>
                 <sp:ProtectionToken>
                     <wsp:Policy>
                         <sp:KerberosToken sp:IncludeToken=
   "http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once">
                             <wsp:Policy>
                                <!--<sp:RequireDerivedKeys />-->
                                <sp:WssGssKerberosV5ApReqToken11/>
                             </wsp:Policy>
                         </sp:KerberosToken>
                     </wsp:Policy>
                 </sp:ProtectionToken>
                 ...
                 <sp:AlgorithmSuite>
                     <wsp:Policy>
                        <sp:Basic128/>
                     </wsp:Policy>
                 </sp:AlgorithmSuite>
               </wsp:Policy>
           </sp:SymmetricBinding>
           ...
           <sc:KerberosConfig xmlns:sc=
           "http://schemas.sun.com/2006/03/wss/server"
           loginModule="KerberosServer"/>
      </wsp:All>
   </wsp:ExactlyOne>
   </wsp:Policy>

Notice the <sp:KerberosToken> element. This is the Kerberos token assertion. It asserts that the Kerberos token from the client is required to authenticate the client to the service and to protect the message. The WssGssKerberosV5ApReqToken11 element specifies that GSS-wrapped Kerberos v5 tokens will be used in the messages, as specified in the The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2, RFC4121.

Also notice the <sc:KerberosConfig> element. It specifies the name of the Java Authentication and Authorization Service (JAAS) login module to use with Kerberos. This JAAS login module, which is KerberosServer in the example, is specified in the <AS_HOME>/domains/domain1/config/login.conf file as shown in the Running the Sample Code section of the tip.

The operation level policy used in the sample is same as in the "Securing Web Services Using WSIT" tip. It specifies that the body and addressing headers should be signed and the body should be encrypted.

Deploying the Web Service

You can build and deploy a WSIT security-enabled web service in the same way as a regular JAX-WS based web service. For information on how to build a JAX-WS based web service, see the tip Developing Web Services Using JAX-WS.

Creating the Client

After you deploy the web service, you can access it from a client program. The steps for building a client that accesses a JAX-WS based web service are described in the tip Developing Web Services Using JAX-WS. However, to build a client that accesses a secured web service through WSIT, you need to configure security for the client.

Configuring Security Information For the Client

To configure security for a client you specify security-related information in a file named wsit-client.xml. This file, which contains a WSDL document, specifies the local security policies to be used by the client and the policies obtained from the service WSDL.

A standalone client, FinancialServiceClient.java, is provided in the sample application package that accompanies this tip. Here is the security configuration for the client in the wsit-client.xml file:

   <wsp:Policy wsu:Id="ClientKerberosPolicy"
     xmlns:sc="http://schemas.sun.com/2006/03/wss/client"
     xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy"
     xmlns:scc="http://schemas.sun.com/ws/2006/05/sc/client">
       <wsp:ExactlyOne>
           <wsp:All>
            <sc:KerberosConfig wspp:visibility="private"
         loginModule="KerberosClient"
            servicePrincipal="websvc/service@INDIA.SUN.COM"
               credentialDelegation="true" />
           </wsp:All>
       </wsp:ExactlyOne>
   </wsp:Policy>

This sample local policy has an element which specifies the name of the JAAS login module to be used with Kerberos on the client. The name is specified in the loginModule attribute. This JAAS login module, KerberosClient in the example, is specified in the <AS_HOME>/domains/domain1/config/login.conf file as shown in the Running the Sample Code section of this tip. The servicePrincipal attribute specifies the name of the service principal for which the client should request a ticket from the KDC. The credentialDelegation element indicates whether the client credentials should be delegated to the service -- in this example, it should. Credential delegation is useful if the server wants to initiate other security contexts on behalf of the client, something that's important for single sign-on in a multi-tier environment.

Running the Sample Code

A sample package accompanies this tip. To install and run the sample:

  1. If you haven't already done so, download JDK 6 from the Java SE Downloads page and install it. The Kerberos support in Metro works only with JDK 6 and later releases.
  2. If you haven't already done so, download the Java EE 5 SDK Update 4 from the Java EE Downloads page and install it.
  3. Download Metro 1.1 from the Metro Project site and follow the installation instructions on the WSIT Documentation page.
  4. Set the WSIT_HOME system property as follows:

    • Open the file <AS_HOME>/domains/domain1/config/domain.xml in a text editor, where <AS_HOME> is the installation directory in which you installed Java EE 5 SDK Update 4.
    • Add the following JVM options to the file:
         <jvm-options>-DWSIT_HOME=${com.sun.aas.installRoot}
         </jvm-options>
         <jvm-options>
         -Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true
         </jvm-options>
         <jvm-options>
         -Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true
         </jvm-options>
      
  5. Specify the JAAS login modules to be used for Kerberos in the <AS_HOME>/domains/domain1/config/login.conf file, as follows:
       KerberosClient {
         com.sun.security.auth.module.Krb5LoginModule required
         useTicketCache=true;
       };
    
       KerberosServer {
         com.sun.security.auth.module.Krb5LoginModule required
         useKeyTab=true keyTab="/etc/krb5.keytab"
         doNotPrompt=true storeKey=true
         principal="websvc/service@INDIA.SUN.LOCAL";
                 };
    

    You can give any names to the login modules, that is, instead of KerberosClient and KerberosServer. You need to refer to these names in the <sc:KerberosConfig> assertion in the WSDL file and in the wsit-client.xml file.

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

  6. Download the sample package for the tip and extract its contents. You should now see the newly extracted directory as <sample_install_dir>/wssec-kerb, where <sample_install_dir> is the directory in where you installed the sample package.
  7. Change to the wssec-kerb/src/fs directory. In the build.properties file set java.home. to the location of the JDK on your system. Set glassfish.home to the installation directory of Java EE 5 SDK Update 4.
  8. Run the sample by entering the following command:
       ant run-sample
    

    You should see the following response:

       balance=1,000,000
       Acknowledgement : successfully deposited.
    

    You can view the message flows by examining the log file for the application server in the <AS_HOME>/domains/domain1/logs directory.

About the Author

Ashutosh Shahi is a member of the Web Services Security group at Sun Microsystems. He currently works on implementation of WS-\* technologies related to security in the Metro web services stack from Sun. Before joining Sun, Ashutosh worked on the development of Apache Axis, an open source SOAP engine from Apache.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Try GlassFish

Connect and Participate With GlassFish
Try GlassFish for a chance to win an iPhone. This sweepstakes ends on March 23, 2008. Submit your entry today.


Comments:

Hello Ashutosh,
This tutorial does not work with jdk-1.6.03 and glassfish-v2 which comes in netbeans bundle, so please help me it's is urgent

Posted by Dhirendra Singh on February 21, 2008 at 05:37 PM PST #

Hello Dhirendra,
You will have to download atleast Metro 1.1 and install it on top of glassfish. As this is a fairly new addition, it is not part of glassfish v2 release. Step 3 in running the sample code asks you to do this.
Have you already done this step? If yes, can you let me know what error you are getting?

Ashutosh

Posted by Ashutosh Shahi on February 22, 2008 at 01:20 PM PST #

Hello Dhirendra,

your exception tells me that either you are not logged in to your KDC (ActiveDirectory) or you have not specified useTicketCache=true in your KerberosClient config.

This exception is at client side so it is not related to keytab. But once your client is able to send message the service will need a keytab file. You can look at http://support.microsoft.com/kb/324144 under section "Generate a UNIX Host Keytab File" on how to generate a keytab file. You will have to transfer this keytab file to your system and specify its path in keyTab property of KerberosServer config

Posted by Ashutosh Shahi on February 24, 2008 at 04:48 PM PST #

Hello Ashutosh,
Thanks for help. when i am running sample code than i am getting following error, tell me what is worng with me.

[java] SEVERE: WSSPIPE0024: Error in Securing Outbound Message.
[java] com.sun.xml.wss.XWSSecurityException: java.security.PrivilegedAction Exception: java.security.PrivilegedActionException: GSSException: No valid credentials provided (Mechanism level: Identifier doesn't match expected value (906))
[java] at com.sun.xml.ws.security.impl.kerberos.KerberosLogin.login(KerberosLogin.java:120)
[java] at com.sun.xml.wss.impl.misc.DefaultSecurityEnvironmentImpl.doKerberosLogin(DefaultSecurityEnvironmentImpl.java:1465)
[java] at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.populateKerberosContext(SecurityClientPipe.java:493)
[java] at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.process(SecurityClientPipe.java:177)
[java] at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
[java] at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
[java] at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
[java] at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
[java] at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
[java] at com.sun.xml.ws.client.Stub.process(Stub.java:248)
[java] at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:135)

[java] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
[java] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
[java] at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)
[java] at $Proxy40.getAccountBalance(Unknown Source)
[java] at simple.client.FinancialServiceClient.main(FinancialServiceClient.java:58)
[java] Caused by: java.security.PrivilegedActionException: java.security.PrivilegedActionException: GSSException: No valid credentials provided (Mechanism level: Identifier doesn't match expected value (906))
[java] at java.security.AccessController.doPrivileged(Native Method)
[java] at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
[java] at com.sun.xml.ws.security.impl.kerberos.KerberosLogin.login(KerberosLogin.java:85)
[java] ... 15 more
[java] Caused by: java.security.PrivilegedActionException: GSSException: No valid credentials provided (Mechanism level: Identifier doesn't match expected value (906))
[java] at com.sun.xml.ws.security.impl.kerberos.KerberosLogin$KerberosClientSetupAction.run(KerberosLogin.java:218)
[java] ... 18 more
[java] Caused by: GSSException: No valid credentials provided (Mechanism level: Identifier doesn't match expected value (906))
[java] at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:663)
[java] at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:230)
[java] at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:162)
[java] at com.sun.xml.ws.security.impl.kerberos.KerberosLogin$KerberosClientSetupAction.run(KerberosLogin.java:210)
[java] ... 18 more
[java] Caused by: KrbException: Identifier doesn't match expected value (906)
[java] at sun.security.krb5.internal.PAData.<init>(PAData.java:87)
[java] at sun.security.krb5.internal.KRBError.<init>(KRBError.java:192)

[java] at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:49)
[java] at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:185)
[java] at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:294)
[java] at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:106)
[java] at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:562)
[java] at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:594)
[java] ... 21 more
[java] Caught Exception: WSSPIPE0024: Error in Securing Outbound Message.
[java] javax.xml.ws.WebServiceException: WSSPIPE0024: Error in Securing Outbound Message.
[java] at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.process(SecurityClientPipe.java:183)
[java] at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
[java] at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
[java] at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
[java] at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
[java] at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
[java] at com.sun.xml.ws.client.Stub.process(Stub.java:248)
[java] at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:135)

[java] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethod
Handler.java:109)
[java] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethod
Handler.java:89)
[java] at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)
[java] at $Proxy40.getAccountBalance(Unknown Source)
[java] at simple.client.FinancialServiceClient.main(FinancialServiceCli
ent.java:58)
[java] Caused by: com.sun.xml.wss.XWSSecurityException: java.security.PrivilegedActionException: java.security.PrivilegedActionException: GSSException: No valid credentials provided (Mechanism level: Identifier doesn't match expected value (906))
[java] at com.sun.xml.ws.security.impl.kerberos.KerberosLogin.login(KerberosLogin.java:120)
[java] at com.sun.xml.wss.impl.misc.DefaultSecurityEnvironmentImpl.doKerberosLogin(DefaultSecurityEnvironmentImpl.java:1465)
[java] at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.populateKerberosContext(SecurityClientPipe.java:493)
[java] at com.sun.xml.wss.jaxws.impl.SecurityClientPipe.process(SecurityClientPipe.java:177)
[java] ... 12 more
[java] Caused by: java.security.PrivilegedActionException: java.security.PrivilegedActionException: GSSException: No valid credentials provided (Mechanism level: Identifier doesn't match expected value (906))
[java] at java.security.AccessController.doPrivileged(Native Method)
[java] at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
[java] at com.sun.xml.ws.security.impl.kerberos.KerberosLogin.login(KerberosLogin.java:85)
[java] ... 15 more
[java] Caused by: java.security.PrivilegedActionException: GSSException: No valid credentials provided (Mechanism level: Identifier doesn't match expected value (906))
[java] at com.sun.xml.ws.security.impl.kerberos.KerberosLogin$KerberosClientSetupAction.run(KerberosLogin.java:218)
[java] ... 18 more
[java] Caused by: GSSException: No valid credentials provided (Mechanism level: Identifier doesn't match expected value (906))
[java] at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:663)
[java] at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:230)
[java] at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:162)
[java] at com.sun.xml.ws.security.impl.kerberos.KerberosLogin$KerberosClientSetupAction.run(KerberosLogin.java:210)
[java] ... 18 more
[java] Caused by: KrbException: Identifier doesn't match expected value (906)
[java] at sun.security.krb5.internal.PAData.<init>(PAData.java:87)
[java] at sun.security.krb5.internal.KRBError.<init>(KRBError.java:192)

[java] at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:49)
[java] at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:185)
[java] at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:294)
[java] at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:106)
[java] at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:562)
[java] at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:594)
[java] ... 21 more

run:

Posted by Dhirendra singh on February 25, 2008 at 06:59 PM PST #

While I have not faced this error before, some googling tells me that it is issue with how your client is registered with the KDC. For example, see:
http://forum.java.sun.com/thread.jspa?threadID=497972&messageID=2358840

It will also help if you could set the -Dsun.security.krb5.debug=true property and send the debug log.

Ashutosh

Posted by Ashutosh Shahi on February 25, 2008 at 11:20 PM PST #

i am also facing the same problem as mentioned by Dhirendra
we created SPN with the following details :

http/cortdnet.test.com:8080 TEST.COM/mgupta5

After creating SPN successfully I am using the same in wsit-client.xml as under -

wsit-client.xml:
servicePrincipal = "http/cortdnet.test.com:8080@TEST.COM"

KerberosServer config:
principal= "http/cortdnet.test.com:8080@TEST.COM"

Pl. help mein resolving the same. Is this the right way to use the same.

Thanks a lot.

Posted by Manu Gupta on February 26, 2008 at 09:29 PM PST #

Hello Dhirendra,

Sorry for the delayed response. Have you been able to resolve your issue by now? Your last debug log shows:
SEVERE: WSS1906: Invalid key provided for encryption/decryption.
java.security.InvalidKeyException: Invalid AES key length: 8 bytes

which means somehow the key which was generated by KDC was not for AES algorithm. The debug log shows that DES key was generated .Can you see your KDC settings if it is enabled for AES 128 encryption? Also, you can make sure only AES 128 encryption is supported for the client principal by generating client principal specifying to use only AES 128 alsogorithm:
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
This is shown in the techtip

Ashutosh

Posted by Ashutosh Shahi on March 09, 2008 at 08:10 PM PDT #

Dear Ashutosh,

Thanks you for your response.

We have been reading a lot about SPN but in fact don’t really understand how to register the same. Wherever we go it explains mapping of user with SPN but does not exactly explain how to register SPN.

We are using following technologies –

1. Java Authentication and Authorization Service (JAAS)
2. Generic Security Services API (GSS-API)
3. Java Metro 1.1
4. Java API for XML Web Services (JAX-WS)
5. Web Service Interoperability Technology (WSIT)
6. GlassFish Application Server (Trying on both)
7. Tomcat Web Server (Trying on both)
8. JDK 1.6
9. Windows 2003 Active Directory
10. Kerberos 5 standard network protocol

1. We created a user dsingh@test.com in Windows Active directory
2. Then we ran ktpass utility as under -

ktpass -princ HTTP/cortdnet.TEST.COM@TEST.COM
-mapuser dsingh
-crypto rc4-hmac-nt
-ptype KRB5_NT_SRV_HST
-pass 12345 -out c:\\krb5.keytab

3. We copy pasted c:\\krb5.keytab to machine hosting web services.
4. We changed the configuration file -
ws-client.xml
login.conf in glassfish

5. We then ran the sample code.
6. We are getting the same error.

Posted by Dhirendra on March 24, 2008 at 11:27 PM PDT #

Whwn I tried ktpass whicle testing it with ActiveDirectory, the only options I remember giving are:
ktpass -princ host/hostname@NT-DNS-REALM-NAME -mapuser account -pass password -out krb5.keytab

If you are giving -crypto option, can you try with aes128-cts value.

Also, shoudn't -ptype be KRB5_NT_PRINCIPAL?

Posted by Ashutosh Shahi on March 26, 2008 at 09:36 PM PDT #

Dear Ashutosh,

Sorry to bother you again but we have tried as below but still getting the error -

Ashutosh -- ktpass -princ host/hostname@NT-DNS-REALM-NAME -mapuser account -pass password -out krb5.keytab

Dhirendra -- ktpass -princ host/CORTDNET@TEST.COM -mapuser dhiru -pass 12345 -out krb5.keytab

we didn't pass -crypto as my system doesn't support it. It supports RC4-HMAC-NT

We have also not passed -ptype

If you have tried this example with Windows Active Directory then we request you to kindly let us know the steps you have followed for successfully implementing your example.

Posted by Dhirendra Singh on March 27, 2008 at 12:29 AM PDT #

What do you mean by "my system doesn't support it. It supports RC4-HMAC-NT". AES128-CTS is the algorithm used in the sample. And as far as I know, Active Directory and Kerberos in JDK 1.6 both support AES128.

Ashutosh

Posted by Ashutosh Shahi on March 27, 2008 at 01:12 AM PDT #

Hi Dhirendra

I had the same problem as you (java.security.InvalidKeyException: Invalid AES key length: 8 bytes) and solved it by putting :

default_tgt_enctypes = arcfour-hmac-md5
default_tgs_enctypes = arcfour-hmac-md5

into my C:/WINDOWS/krb5.ini file.

I also used /crypto RC4-HMAC-NT as arguments to ktpass, but I think this is default, and hence not necessary.

Hope this helps you!

/Mathias

Posted by Mathias Nicolajsen Kjærgaard on April 10, 2008 at 08:55 AM PDT #

Hello Mathias,

Good to know that you could get it working. To know the identity of the user calling the web service , you could do the following:

Subject subj = SubjectAccessor.getRequesterSubject(wsContext);

where wcContext is:
@javax.annotation.Resource
WebServiceContext wsContext;

Then, you can obtain a KerberosPrincipal from subj.getPrincipals() set. This KerberosPrincipal can be queried for getName() to get the client identity.

BTW, if you also want to do credential delegation, the PrivateCredentials Set of Subject has GSSCredential available, if credential delagation was enabled.

HTH,
Ashutosh

Posted by Ashutosh Shahi on April 14, 2008 at 02:42 PM PDT #

Hi Ashutosh,

Thank you for your answer.
I have tried calling SubjectAccessor.getRequesterSubject(wsContext), but it returns null. Do you have any idea why this is the case?
I don't know if it has any relevance, but according to the API doc the getRequesterSubject should have a ServletEndpointContext or a ProcessingContext as argument, but my injected WebServiceContext is a com.sun.xml.ws.server.InvokerTube$1 which does not seem to implement/extend any of the two supported contexts.

An other note: SubjectAccessor seems to be implementation specific. Is there a reason why the standard WebServiceContext.getUserPrincipal() cannot be used?

Regards
Mathias

Posted by Mathias Nicolajsen Kjærgaard on April 15, 2008 at 06:03 AM PDT #

Mathias,

This was introduced after Metro 1.1, so you will need to take the latest nightly or the upcoming Metro 1.2 release of Metro for this to work.

See this thread for more on this:
http://forums.java.net/jive/thread.jspa?messageID=253195

Ashutosh

Posted by Ashutosh Shahi on April 15, 2008 at 01:37 PM PDT #

Hi Ashutosh,

I see that you are using ticket cache on the client side to fetch the caller principal, which seems fine when the client is JSE. For JEE client, do you still use ticket cache ? To get the ticket from the ticket cache, a kinit operation needs to be performed. For JEE client, how will the kinit take place ?

thanks
Moushmi

Posted by moushmi on December 24, 2008 at 04:08 AM PST #

This article is pretty good. I used this article to consume a WS with kerberos token.
I have added few steps to consume a WS with kerberos security. This may be helpful for somebody, who try to implement a standalone java client uses sun metros.

http://prasannaramaswamy.blogspot.com/2009/09/webservice-client-with-kerberos.html

Posted by Prasanna on September 04, 2009 at 08:48 AM PDT #

I have a metropcs cell phone service that included metroweb access which used to work fine but since the 20th of Sept. 2010 every time i tried to use the metroweb i get the following error everytime and have called customer care 611 and had no luck resolving this issue help please!!!! error message is cannot resolve hostname.....

Posted by Melinda Lopez on October 11, 2010 at 11:48 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

edort

Search

Archives
« September 2015
SunMonTueWedThuFriSat
  
1
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
   
       
Today