harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Hamid <ar...@cornell.edu>
Subject Re: Kerberos service provider
Date Wed, 07 Dec 2005 14:57:24 GMT
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
> 

Mime
View raw message