Integration

Oooops, sorry for that.

So, my soft must :
- retrieve the KerberosTokenProfile,
- extract the principal and validate that the calling entity is allowed to request the requested service,
- send the request to the WebService if it is OK,
- and then sign the WebService server response.

My question is: what should I use to sign the outgoing message?

I've got the feeling I should use the shared key embedded in the KerberosTokenProfile the calling entity obtained to request the service, but I'm not sure of that, and I don't even know how to retrieve this shared key...

Does someone know how I should proceed?

Many thanks in advance

Hey, I've just implemented this myself over SOAP which has to be interoperable with a .NET kerberos secured message. I went through all the same questions as you.....It is possible, however, there is one MAJOR stumbling block on the server side that the Java GSS implementation makes it impossible to actually get hold of the session key after accepting a security context.

If you read one of the WS-Security Kerberos Binding document (I've found ones by IBM and Oasis as well as Microsoft specific ones), they refer to using the "shared secret" to sign and/or encrypt the messages. This is in fact the shared key you mention - and is more commonly referred to as the "session key". As it is only known by the client, the target service and the KDC it is the best option for digital signatures in the SOAP comms.

If you are wanting to implement this in Java, you will need to learn how to use the JAAS login and GSS API to achieve this. There are some good Sun tutorials and loads and loads of threads in this group. It is a fairly simple API, once you understand it.

The pseudo code is something like:

Client side (you don't need to know this, but it helps to understand the whole process from a Java perspective):
1. Login using JAAS (this authenticates to the KDC and you get a Subject object which you need to keep).
2. Create a GSS manager and a GSS server name which points to the target service.
3. Initiate a GSS context. This is the first step in setting up the session between the SOAP service/client.
4. The response from (3) is the service ticket (byte[]) which you then Base64 encode and put into the SOAP message as a binary security token. This has the client principal name and the session key encoded in it and is encrypted using a secret key that only the server knows (and the KDC), therefore only the server can decrypt the ticket. The KDC does all this encrypting before it gives you the ticket byte[].
5. Digitally sign any parts of the message that you want, using the session key.
6. Send to the SOAP service.

Server side:
1. Login using JAAS - this only needs to be done once, not on every request. Storekey needs to be set to true in the JAAS configuration parameters.
2. The act of authenticating with the KDC causes the servers secret key(s) to be downloaded and stored in the JAAS subject object. These keys are used to decrypt the incoming service ticket (by the GSS API).
3. Base64 decode the incoming binary security token, and pass it to the GSS accept security context method. (GSSContext.acceptSecContext()). This decrypts the ticket using the server's secret key, and gives you access to the client principal name.
4. Write some code to authorize against your domain controller that the client principal is in the correct user group to access your server (as there are no GSS methods for doing this).
5. Get the session key and use it to verify the digital signatures in the incoming message, as it will most likely contain them. However, the session key is not available in the GSS libraries when you are on the server side. I even had discussion with one of the actual Sun security guys and they confirmed this (IMO this is an oversight on their part). I had to do my own build of the Kerberos libraries and get it to drop the session key into the Subject during an acceptSecContext() call. The other option is to write your own code to decode the service ticket and extract the session key yourself.

Server outgoing notes:
1. From this point on, the session is initiated, so the server will respond to the client with a Security Token Reference element with the base 64 encoded SHA-1 thumb print of the original service ticket byte[]. Info about this can be found in the WS-Security Kerberos Binding documents. Its pretty simple: grab a message digest "SHA1" instance and encode the raw service ticket bytes with it, then base 64 encode the SHA1 encoded bytes.
2. The client should be able to send future SOAP messages for that session's lifetime with the same SHA1 reference, instead of instantiating a new session with every request sent to the server. I haven't tested this out with .NET yet (as the services I interop with are written by another company and I can't control them at all), but its a case you should probably at least test for.

Edited by: antsbull on Mar 23, 2008 1:05 PM

Hi,

In Sun's Metro web services stack (https://metro.dev.java.net/), we already provide Kerberos token profile support, and we have tested that it interoperates with .NET (3.0 and 3.5). See :
http://blogs.sun.com/enterprisetechtips/entry/building_kerberos_based_secure_services
and
http://blogs.sun.com/ashutosh/entry/running_kerberos_token_profile_scenario
for more details.

Thanks,
Ashutosh

Hi antsbull,

i'm writing a SSO using Kerberos tickets for my webapp that have an embedded tomcat running. I have to write a servlet filter (valve) that recieve the http request from the browser and activate SPNEGO in the browser to get a service ticket from the KDC.

1- if the browser couldn't get a service ticket what does it then?
2- where is the shared session key between the server and KDC been saved? does KDC generate it every time a service ticket it aquired? or one time forever?
3- is it complicate to write own code to unpack the service ticket. If not can u give some sample or clues how to code it? and how to validate it? what should be checked in?

Hi alim,

3. If you want to decode a service ticket, on the server side - the following blog has complete code example that does it for you:

[http://thejavamonkey.blogspot.com/2008/05/how-to-decrypt-kerberos-gss-ap-req.html]

1. I don't know much about getting a browser to authenticate with a KDC and grab service tickets - you'll have to look elsewhere for that info sorry.

2. The shared session key (which is for the session between the client and the server) is actually stored in the service ticket. The service ticket is encrypted with the secret key of the server, so that only the server can decrypt the service ticket. The decoding code on my blog above will let you access this session key on the server. Whether you need the session key long term or not depends on whether every request made to your server contains a new service-ticket. If it does, you won't need a long term session key as you'll be able to grab it out of the subsequent requests.

Hi antsbull,

Thanks alot for ur answer. The link is realy good. I found the answers about the KDC and browser here:

http://forum.java.sun.com/thread.jspa?threadID=5276055&tstart=0

Alim

Hi antsbull,

in fact my second question was about the secret key between the KDC and the server, which the server use to dencrypt the service ticket.

How to create it and where to save it? (i had a response saying it should be saved in a keytab file but how to create it ? how does it look like?)

When an identity (either client or server) authenticates successfully against the KDC, using a JAAS login, JAAS downloads the secret key(s) for that identity and puts them in the JAAS subject object.

So, once you have done an authenticate against the KDC you will have your secret key. Also note that once they are in your subject object, then using the GSS API with that subject object results in GSS automatically using the secret key to decode incoming tickets (tgts,service tickets) meant for that identity.

You can access these keys using the getter methods on the subject instance.

-----

Also note that if you need access to the session key between the client and server, then that is a different story. Client-side, JAAS puts it in your subject instance. Server side, it isn't accessible and you have to decode the service ticket yourself to get the session key.

Many thanks antsbull.

The way is clear so far. I' ve got things together & i' ll start testing it. I' may come back with more technical questions.

Hey antsbull,

i have followed all the steps you mentioned in the message.
however i am not able to complete the last step

Client side (you don't need to know this, but it helps to understand the whole process from a Java perspective):
1. Login using JAAS (this authenticates to the KDC and you get a Subject object which you need to keep).
2. Create a GSS manager and a GSS server name which points to the target service.
3. Initiate a GSS context. This is the first step in setting up the session between the SOAP service/client.
4. The response from (3) is the service ticket (byte[]) which you then Base64 encode and put into the SOAP message as a binary security token. This has the client principal name and the session key encoded in it and is encrypted using a secret key that only the server knows (and the KDC), therefore only the server can decrypt the ticket. The KDC does all this encrypting before it gives you the ticket byte[].

-- Completed upto 4

Not able to complete this
*5. Digitally sign any parts of the message that you want, using the session key.*

6. Send to the SOAP service.

Do you have any pointers on how can i sign the message body.

thanks for the help

durgesh Vasmatkar