Java GSS-API and kerberos Service Tickets

Anuraggwl anuraggwl at yahoo.com
Wed Dec 10 14:26:32 EST 2008


To give some background of my application, i am developing web application
which will support Kerberos SSO on windows platform. It means that if some
user logs in to Windows Client Machine and opens my application then my
application will not throw any login screen . It will use Logged-in user
credentials to login to my system.

>From browser perspective, i am using SPNEGO support to get Kerberos ticket.
My Web application can be deployed in reverseProxy or load balanced
environments. In addition to that, there is a requirment to support kerberos
login even if some end user tries to access internal app server directly
i.e. by passing proxy. 

For example, i have deployed my appllication on node01.mydomain.com and
revese proxy url is myapp.mydomain.com. So basically user can use both url
to access my application.

URL1 : myapp.mydomain.com ( Reverse Proxy )
URL2: node01.mydomain.com ( actual app server )

SInce i am using browser SPNEGO support so browser takes care of creating
SPN to get Service Ticket from KDC. For example, if enduser opens URL1 (
myapp.mydomain.com ) then browser create SPN like below:

HTTP/myapp.mydomain.com at MYDOMAIN.COM

However, if enduser access intenal server URL2 ( node01.mydomain.com ) then
browser create SPN like below:

HTTP/node01mydomain.com at MYDOMAIN.COM

I could register both these service in different accounts in Windows KDC.
however, to make things simpler i tried putting all services in same
account. 

However, irrespective of how i create the SPN's in KDC, on my server side
code, i can have only one Service which can be either
"HTTP/node01.mydomain.com at mydomain.com" or
"HTTP/myapp.mydomain.com at mydomain.com"

i dont know is there a way in Java GSS API where i can load Java Subject
objects with services credentials  from multiple keytab file.

It seems that Java GSS API reads "principal" property from Kerberos conf
file. If map both the URL's to same user account in KDc and then register
""HTTP/myapp.mydomain.com at mydomain.com"" as principal in kerberos
configuration file then my server code can accept secuity context with any
of the service ticket ( i.e.  ( HTTP/myapp.mydomain.com at mydomain.com" Or
HTTP/node01.mydomain.com at mydomain.com"

I dont know is this the correct behavior where browser request the Service
Ticket for different URL URL2( or Service) and server code validates using
some other account URL1 ?

Is there a way to accept security context by overriding Principal attribute
in kerberos conf file?



Douglas E. Engert wrote:
> 
> GSSName takes service at host, not principal.
> GSSName does not take a realm. The realm is determined
> internaly to the GSS.
> 
> So in your case the GSSname would be HTTP at SPN2
> 
> (Still don't know why you have to use a single AD account with
> two SPNs, rather then two separate accounts.)
> 
> Anuraggwl wrote:
>> Can someone please tell me what should be the correct behaviour of Java
>> GSS
>> API if get the service token for Service Principal 1 ( SPN1) and on
>> server
>> accept it using Service Principal 2( SPN2) where both service principal
>> are
>> mapped to single user account in KDC( windows 2003).
>> 
>> I am using windows 2003 as KDC and both SPN1 & SPN2 are registered in
>> single
>> user account. for example, if my user account is websvr then i run
>> following
>> command setspn to set these SPN's to websvr account.
>> 
>> setSPN -A HTTP/SPN1 at MyRealm websvr
>> setSPN -A HTTP/SPN2 at MyRealm websvr
>> 
>> I have also mapped SPN1 as primary SPN using ktpass mapuser.
>> 
>> In my Java Client program, i request the service ticket for
>> HTTP/SPN2 at MyRealm and pass it to Java Server code. On Server side, i have
>> following kerberos config file
>> 
>> com.sun.security.jgss.accept  {
>>   com.sun.security.auth.module.Krb5LoginModule required isInitiator=false
>>   storeKey=true 
>>   doNotPrompt=true 
>>   useKeyTab=true
>>   keyTab="c://websvrKeys.keytab" 
>>   principal="HTTP/SPN1 at MyRealm" 
>>   realm="MyRealm"
>>   debug=true;
>> };
>> 
>> Please note that i am using JDK5 and i cant upgrade to JDK6 so i cant use
>> isInitiator flag to false to avoid contact with KDC for authentication.
>> 
>> Is this Principal Name is mandatory attribute here ?
>> 
>> Since HTTP/SPN1 is my primary SPN and JDK5 GSS first perform the
>> authentication in KDC so i cant use HTTP/SPN2 as principal in kerberos
>> config file.
>> 
>> I am seeing following behaviour.
>> 
>> 1) Java GSS Server code is able to validate the service ticket ( for
>> SPN2) 
>> and on server, we still have SPN1 in conf file. is this correct behaviour
>> ?
>> 
>> It seems in other Kerberos API,i get "WRONG PRINCIPAL IN REQUEST" ?
>> 
>> 2) is it possible to accept kerberos ticket using some other GSSName. for
>> example, my config contains principal as HTTP/SPN1, can i use HTTP/SPN2
>> in
>> my server side code like below :
>> 
>>                 GSSName sname =  mgr.createName("HTTP/SPN2 at myRealm,
>> null);
>> 
>>                 GSSCredential clientCreds =  mgr.createCredential(sname,
>>                                              
>> GSSCredential.DEFAULT_LIFETIME,
>>                                               krb5Oid,
>>                                               GSSCredential.ACCEPT_ONLY);
>> 
>> When i do that i get Error "Unable to get kerberos key in keytab."
>> However,
>> i have both SPN1/SPN2 in keytab file.
>> 
>> Note that if in my server code, if i put GNAME as null then JAVa GSS API
>> gets GSSName from kerberos config file by reading principal.
>> 
>> 
> 
> -- 
> 
>   Douglas E. Engert  <DEEngert at anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 

-- 
View this message in context: http://www.nabble.com/Java-GSS-API-and-kerberos-Service-Tickets-tp20924707p20942354.html
Sent from the Kerberos - General mailing list archive at Nabble.com.




More information about the Kerberos mailing list