harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mishura, Stepan M" <stepan.m.mish...@intel.com>
Subject Kerberos service provider
Date Wed, 07 Dec 2005 11:47:50 GMT
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


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?



Stepan Mishura

Intel Managed Runtime Division


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message