Kerberos service provider

["Mishura, Stepan M" <st...@intel.com>]

A service provider mechanism is aimed to provide an access to some
service implementation. A service can be implemented by different
vendors in quite different ways (different features, favorite bugs :-),
backward compatibility and so on). We can consider Kerberos as some type
of security service and plugged any Kerberos implementation as existing
security services using common provider mechanism. It will allow
choosing preferred implementation in pluggable manner. 

 

Kerberos is used in java in the JAAS framework and GSS-API
(org.ietf.jgss package). A common scenario is looks like:

Credentials (KerberosKey, KerberosTicket) must be obtained first and
stored in Subject object, this can be done with a Kerberos login module.
Then stored credentials are used by underlying Kerberos mechanism for
GSS-API.

 

What about moving all Kerberos functionality to provider layer?

I suggest the following: all public API are just wrappers that calls
corresponding Kerberos service provider interface (SPI) methods. For
example, a login module can use methods for AS exchanges and
KerberosTicket class can use SPI methods to refresh a ticket. 

 

This unifies approach for employing Kerberos technology in Java: all you
need is to implement specified service provider interface. IMHO,
designing Kerberos SPI also can:

* Allow using different Kerberos implementations

* Stimulate java Kerberos open source implementation.

 

I'd like to ask folks whether it make sense to try to do it or not?

Did I miss something? Does anybody happy with the current design without
Kerberos service?

 

Thanks,

Stepan Mishura

Intel Managed Runtime Division

 

Re: Kerberos service provider

[Aaron Hamid <ar...@cornell.edu>]

Hi guys,

  Yes, it is already pluggable at the module level, but perhaps the salient question is whether, when moving an app across operating system platforms, the app should require a "reconfiguration" to use, e.g., com.apple.MacOSX.NativeKerberosModule, or com.microsoft.Windows.NativeKerberosModule, or org.otherOS.NativeKerberosModule, or whether some "standard" module should supply an SPI of *its own* to avoid this reconfiguration.  I believe to some extent this already works on Windows and Unix (at least in the Sun VM, judging only from public documentation of 'useTicketCache' login configuration option), although I am not sure how (different classes/native-libraries distributed with os-specific runtimes maybe?).  I grant that the choice to introduce more SPI layers can be a subjective design/aesthetic issue.

  For our use this question is relevant not only for the convenience of avoiding reconfiguration, but also the necessity to attempt as much as possible to integrate with existing, accepted, native authentication dialogs for security purposes (i.e. users should not be taught to enter their Kerberos credentials into any old dialog that pops up).  Maybe OSGi can yet again be applicable to this area.

Aaron Hamid
CIT/ATA
Cornell University


Peter Edworthy wrote:
> Hello,
> 
> [snip]
> 
>>Kerberos is used in java in the JAAS framework and GSS-API
>>(org.ietf.jgss package).
> 
> [snip]
> 
>>What about moving all Kerberos functionality to provider layer?
> 
> [snip]
> 
>>I suggest the following: all public API are just wrappers that calls
>>corresponding Kerberos service provider interface (SPI) methods. For
>>example, a login module can use methods for AS exchanges and
>>KerberosTicket class can use SPI methods to refresh a ticket.
> 
> [snip]
> 
>>Did I miss something? Does anybody happy with the current design without
>>Kerberos service?
> 
> [snip]
> 
> I believe this is a ClassLib implementation question, I don't see that any
> changes would be required in the JVM to use this.
> 
> The JDK only defines the data carriers, KerberosPrinciple, KerberosKey and
> KerberosTicket. The actual logic is provided in a LoginModule which is
> accessed from LoginContext which acts as a factory to authentication
> providers. It is configured by file through the Configuration object.
> 
> Also the JAAS authentication implementations do not come as part of the
> JRE, but are provided by additional libraries. It's all very much like JCE
> or even JDBC.
> 
> So basically I think it is already pluggable, and if it weren't it
> wouldn't require a JVM change only a ClassLibs change.
> 
> Sorry if it sounds harsh, I'm trying not to be
> Thanks
> Pete
> 

Re: Kerberos service provider

[Peter Edworthy <pe...@edworthy.org>]

Hello,

[snip]
> Kerberos is used in java in the JAAS framework and GSS-API
> (org.ietf.jgss package).
[snip]
> What about moving all Kerberos functionality to provider layer?
[snip]
> I suggest the following: all public API are just wrappers that calls
> corresponding Kerberos service provider interface (SPI) methods. For
> example, a login module can use methods for AS exchanges and
> KerberosTicket class can use SPI methods to refresh a ticket.
[snip]
> Did I miss something? Does anybody happy with the current design without
> Kerberos service?
[snip]

I believe this is a ClassLib implementation question, I don't see that any
changes would be required in the JVM to use this.

The JDK only defines the data carriers, KerberosPrinciple, KerberosKey and
KerberosTicket. The actual logic is provided in a LoginModule which is
accessed from LoginContext which acts as a factory to authentication
providers. It is configured by file through the Configuration object.

Also the JAAS authentication implementations do not come as part of the
JRE, but are provided by additional libraries. It's all very much like JCE
or even JDBC.

So basically I think it is already pluggable, and if it weren't it
wouldn't require a JVM change only a ClassLibs change.

Sorry if it sounds harsh, I'm trying not to be
Thanks
Pete