X

Building Kerberos-Based Secure Services Using Metro

Guest Author

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:










alt="Securing Client Access to a Service Using Kerberos" height="394" width="600">
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.

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









alt="Try GlassFish" padding="5" />


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.



Join the discussion

Comments ( 18 )
  • Dhirendra Singh Friday, February 22, 2008

    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


  • Ashutosh Shahi Friday, February 22, 2008

    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


  • Ashutosh Shahi Monday, February 25, 2008

    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


  • Dhirendra singh Tuesday, February 26, 2008

    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:


  • Ashutosh Shahi Tuesday, February 26, 2008

    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


  • Manu Gupta Wednesday, February 27, 2008

    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.


  • Ashutosh Shahi Monday, March 10, 2008

    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


  • Dhirendra Tuesday, March 25, 2008

    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.


  • Ashutosh Shahi Thursday, March 27, 2008

    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?


  • Dhirendra Singh Thursday, March 27, 2008

    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.


  • Ashutosh Shahi Thursday, March 27, 2008

    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


  • Mathias Nicolajsen Kj&aelig;rgaard Thursday, April 10, 2008

    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


  • Ashutosh Shahi Monday, April 14, 2008

    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


  • Mathias Nicolajsen Kj&aelig;rgaard Tuesday, April 15, 2008

    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


  • Ashutosh Shahi Tuesday, April 15, 2008

    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


  • moushmi Wednesday, December 24, 2008

    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


  • Prasanna Friday, September 4, 2009

    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


  • Melinda Lopez Monday, October 11, 2010

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


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.