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
