The default credential acquisition model for Java GSS-API requires credentials to be present in the current Subject. Typically, the credentials are placed there after a JAAS login by the application.
Client and server applications typically perform JAAS authentication using the Kerberos login module. Upon successful authentication the TGT is stored in the Subject's private credentials set and the Kerberos principal is stored in the Subject's principal set. At the server-end the secret key is stored in the Subject's private credentials set. If there are no valid credentials in the current Subject, Java GSS provider attempts to obtain new credentials by invoking a JAAS login itself. This is when the default JAAS entries "com.sun.security.jgss.initiate" and "com.sun.security.jgss.accept" are read from the JAAS configuration file, using the desired configurations that you provide, such as the keytab at the server-end. You can configure JAAS Krb5LoginModule to be an "acceptor" only at the server-end. This option is available starting from Java SE 6, and will be backported to earlier releases. For details on this option, check the javadoc on Krb5LoginModule: http://download.java.net/jdk6/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html Seema Olfmatic wrote On 09/07/06 05:41,: >Hello, > >Please help me, I still don't get it: >I want to accept a secure context on my server. As far as I learned, the >server does not have to contact the KDC to do so, because the shared secret is >stored in a keytab file created on the KDC and then stored at the server. But >I made a different experience. > >This is my code: > > Oid tKrb5Oid = new Oid("1.2.840.113554.1.2.2"); > GSSManager tGSSManager = GSSManager.getInstance(); > String tPrincName = "servicename/[EMAIL PROTECTED]"; > GSSName tServerName = tGSSManager.createName(tPrincName, > GSSName.NT_USER_NAME); > GSSCredential tServerCredential = > tGSSManager.createCredential(tServerName, > GSSCredential.INDEFINITE_LIFETIME, new > Krb5MechFactory().getMechanismOid(), > GSSCredential.ACCEPT_ONLY); > GSSContext tSecureContext = tGSSManager.createContext(tServerName, > tKrb5Oid, tServerCredential, GSSContext.DEFAULT_LIFETIME); > byte [] tInToken = aToken; > byte [] tOutToken = tSecureContext.acceptSecContext(tInToken, 0, > tInToken.length); > >If I execute this code in a PrivilegedAction after loggin in to the KDC with >the Krb5LoginModule, everything is fine. Now what I want is the server to >accept the secure context WITHOUT trying to contact the KDC. Do I have to >login with the Krb5LoginModule even though? Or can the above code also be >executed without prior KDC-Login? >But then how do I tell the server application where to find the keytab file? >As far as I know, the keytab file is configured in the configuration of >LoginModules: > >JaasLogin { > //Kerberos single-sign-on login module > com.sun.security.auth.module.Krb5LoginModule required debug=true > useKeyTab=true keyTab=C:/krb5.keytab ; >}; > > >But if i never call > > LoginContext tLoginContext = new LoginContext("JaasLogin"); > tLoginContext.login(); > final Subject tSubject = tLoginContext.getSubject(); > >then how can the application know that it shall use a keytab and where to find >it? > >IF I login with the Krb5LoginModule, the server looks for the KDC which is not >what I want. >IF I do not login with the Krb5LoginModule, I get the error message "Attempt >to obtain new ACCEPT credentials failed", which seems clear to me because the >server application doesn't know anything about the keytab file. >What do I have to do? Login or no Login? > >Thanks for any help. > >Florian > >________________________________________________ >Kerberos mailing list Kerberos@mit.edu >https://mailman.mit.edu/mailman/listinfo/kerberos > > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
