Hi Valerie
Currently, a Kerberos (in JGSS or SASL) service must know the exact
service name it is serving with (say, http/my.host.com). This is not
true any more in today's virtualized world in which a service might be
serving clients from different networks by exposing different service names.
This is similar to the TLS SNI extension, where different clients
accessing the same server with different names. In the case of TLS, the
server needs to find different certificates to send back the client, in
Kerberos, the server needs to use different keys to decipher the service
ticket.
In today's JAAS, JGSS or SASL design:
1. In JAAS, you must setup a principal value for Krb5LoginModule,
normally in the JAAS login file. Without the principal, Krb5LoginModule
does not know what keys to load from a keytab file.
2. In JGSS, the chance is little better, the service GSSContext is
created with
GSSManager.createContext(GSSCredential myCred)
Here the myCred can be null so that the credential can be decided by the
Krb5LoginModule.
3. In SASL, when creating SaslClient or SaslServer [1], the protocol and
serverName must be supplied non-null to create a GSSName with the form
service@serverName
In order to support multiple service names, we need to make some
changes. First, this is the glossary I'm going to use:
a concrete name: http/my.host.com
a half-concrete name: http/*
a wild name: *
Here are the proposed changes:
1. In JAAS config file, the principal can be non-concrete, which means
when a keytab is loaded, any key inside it might be used later. To be
backward compatible, a principal value still must be provided.
Otherwise, a NameCallback might be triggered.
2. In SASL, the serverName on the SaslServer side can be missing, which
means it's willing to accept connections with any hostname to this
service. Normally, the service should still be specified, and the result
is a half-concrete name: "http/*" in Kerberos.
3. This means in JGSS, we need to support GSSCredential with a
half-concrete GSSName. For example, the GSSName "http@*" means a connect
to any host is allowed, as long as the service is http.
1'. Back to JAAS, We'll also allow this half-concrete name in JAAS
config file.
What we are not going to support or at least not documented:
1. More liberal host name, say, http/*.host.com
2. Multiple service support in SASL, say, */my.host.com.
After these changes, the choice of a final concrete Kerberos service
principal name is an intersection of three filters:
1. The principal in JAAS config
2. The myCred when creating a service GSSContext
3. The peer requested by the initiator
The calculated result should be a concrete principal name. This can be
guaranteed since #3 above is already concrete.
If there is already a conflict between 1 and 2, the service can refuse
to launch at all.
Note: in the TLS krb5 ciphersuite, the #3 above is not concrete because
the server does not know what service principal is. There are 2
workarounds for this:
1. Get the princ name from the SNI extension or some other
Kerberos-specified extension
2. The JAAS config file already provides a concrete principal.
Thanks
Max
[1]
http://download.oracle.com/javase/7/docs/api/javax/security/sasl/Sasl.html
