This content has been marked as final. Show 6 replies
How is the data signed? In JGSS, normally the sender use getMIC() to create a token and the receiver can check it with verifyMIC(), all key info is encapsulated inside GSSContext.
My services/clients have to be interoperable with .NET kerberos enabled SOAP applications. I'm pretty sure that the .NET implementation that we are interop-ing with follows the oasis WS Security spec where it uses a shared session key on the client side to generate a signature, and then on the server side, verifies it by again calculating the signature. The signature algorithm in question is HMAC SHA-1. If I didn't need the interoperability, the MIC methods would have probably worked well for my needs.
On my client side, I'm signing the SOAP message successfully, using the correct signature algorithm (HMAC SHA-1), and passing in the session key that I get from the ServiceTicket as the secret key that the signature algorithm uses.
I can't access this session key on the client side, even after the security context has been established, so I can't verify the message signature. Is there any way of accessing this shared session key through the Java API's?
The following snippet from the actual Oasis kerberos SOAP spec, also mentions potentially using the "Kerberos sub-key" which is found in an "authenticator". I don't have a clue about what that means - any ideas?
When a Kerberos ticket is referenced as a signature key, the signature algorithm [DSIG] MUST be a hashed message authentication code. When a Kerberos ticket is referenced as an encryption key, the encryption algorithm MUST be a symmetric encryption algorithm. The value of the signature or encryption key is constructed from the value of the Kerberos sub-key when it is present in the authenticator or a session key from the ticket if the sub-key is absent, either by using the Kerberos sub-key or session key directly or using a key derived from that key using a mechanism agreed to by the communicating parties.
As far as I understand, it seems this SOAP spec is based on Kerberos and directly makes use of the Kerberos keys. Hence it's at the same level as GSS: both use Kerberos as the underneath authentication/authorization mechanism. If this is true, since Java only provides API at JGSS level, there's no public API on Kerberos.
As for the sub-key, sometimes the client and the server may use the session key to negotiate a new key, called sub-session key, for temporary use. Read RFC 4120 for it.
Thanks. I also had a look at Sun's metro web service framework, which apparently supports Kerberos SOAP auth, and it looks like they have completely replaced the normal JVM Kerberos API with new ones in there, to allow access to additional features.
Using metro is not an option, so I might have to look at its source code to see if I can re-use some of it
(Its an old thread but still trying my luck to see if anyone is monitoring it.)
We have to do a POC demonstrating the interoperability between Java and WCF for WS-Security 1.1 policy with Kerberos tokens. Basically, we need to put the Kerberos token into the SOAP Header along with signing of the message.
We have zeroed in on using Metro 2.0 as that supports Kerberos profile but not able to get the signing part to work. From your posts earlier, I can see that you have been able to achieve the same. Thus I will appreciate if you can post in some code sample on how to sign the message with the session key from the Kerberos token.
If you decide to post in your sample code, you can do so to bikash.bagaria[at]gmail[dot]com
Thanks in advance.
Just noticing your post that I have the same problem, signing the Kerberos Token profile request from Java
This is my thread but I've not got any responses so far unfortunately:
Perhaps we could share notes are try some other ideas between us?