Subject: Re: Java GSS bindings (fwd)

From: Mayank Upadhyay <[email-masked]>
Date: Thu, 4 Feb 1999 10:10:37 -0800 (PST)

It appears that there are two issues that we need to work on in order
to make progress on the GSS-API Java bindings.  One is the issue of
whether the application programmer should see GSS-API interfaces or
whether he/she should see concrete classes; the other is the issue of
whether the GSS-API should be treated as a veneer with a provider
interface for mechanisms to fit underneath, or whether the mechanisms
themselves should directly implement the GSS interfaces.

(1) Veneer or not?
--------------------

There are two approaches to how the GSS-API can be viewed.  The first one
is that taken by the current Java bindings draft where the GSS-API is a
middle layer of classes (or interfaces) between the application program
and the actual security mechanism.  The advantage of this method is that
the actual instantiation of and the maintaining of a reference to the
underlying mechanism is hidden from the application program in this middle
layer.  This seems like a good thing to have in a multi-mechanism
environment for many reasons, one of which is that the application program
might be using SPNego (RFC 2478) as the default context establishment
mechanism expecting a transparent switchover to the negotiated real
mechanism at runtime as it continues making GSS calls.  This is trivial to
do if it happens inside a mechanism independent middle layer that
encapsulates the references to the specific underlying mechanism classes
from the application program.

The second approach is that which Michael Smith proposes, which is that
the application level GSS be interfaces that the mechanism classes
themselves implement.  As a result the application programmer directly
instantiates the mechanism classes but has them "typecast" in a sense to
the GSS-API base interfaces.  This approach would work well except for two
issues that bother me: 

(a) How does SPNego fit in?  Once an application obtains a reference to an
object that, for the most part, is a security mechanism (even though it
may be guise of a GSS-API interface), the reference cannot change to an
object that is a different security mechanism without the application
program instantiating the new class. Then how would the application
transparently switch from using SPNego to a real mechanism? One can
certainly devise ways to do this that get more complex on the implementors
side and also somewhat more tedious than necessary on the application
programmers side. 

(b) If we define a mechanism that has classes directly implementing the
GSS-API interfaces, then would it make sense for that mechanism's
implementation of the GSSCredential interface to implement GSS_Add_Cred? 
The RFC describes the GSSCredential more like a container class for
credential elements from different mechanisms.  Does it make sense for
mechanism A's implementation of GSSCredential to allow credential elements
from other mechanisms to be added to it?  It seems natural that this class
should be a generic implementation at a level above the security
mechanisms.  Yes, the security mechanisms' credential elements would have
to implement some other simpler interface in order for this GSSCredential
to reference them and query them.  But what's so hard about that?  The
same problem presents itself with the GSSName interface. 

In summary, it seems like implementing the GSS-API in a two layered
approach would be better:  One layer forms the middle veneer and the
other layer consists of different mechanisms that plug in underneath,
transparently to the application programmer.

(2) Interface or Concrete Classes 
----------------------------------

Assuming that I have been successful in making my case for a two
layered approach to implementing the GSS-API framework, I venture to
say that it is best to use concrete classes for the top layer and
interfaces for the bottom layer.

To begin with, having interfaces at the bottom layer is the obvious
choice for reasons that people have already mentioned on this alias.
The bottom layer might consist of, say, Kerberos classes.  Your
Kerberos classes may be derived from other classes depending on your
needs and your tools.  All that they should be required to do is
implement a service provider interface (SPI) that will allow the upper
layer GSS veneer to reference them.  The bottom level Kerberos classes
are then free to implement as many interfaces as they like, and to
inherit from a concrete class from anywhere as they please; this
freedom to do multiple inheritance in the Java way was justifiably a
major concern that was raised on this alias.

Next, through a simple class registration mechanism the GSS veneer can
easily instantiate the appropriate implementations of the SPI without
the application programmer's intervention.  The class registration
mechanism will help translate the OID of the mechanism required to the
correct mechanism classes, without depending on any classpath
structures which was another major concern raised on this alias.

The upper GSS veneer, on the other hand, is a slightly different
animal.  On one client site there need only be one implementation of
this veneer that gets used so long as the veneer understands a fixed
SPI (for any security mechanism to plug in underneath it.)  In other
words, while there will be many implementations of underlying
mechanisms, there will be only one implementation of the veneer that
is really needed to use all of them.

This single implementation of the veneer that the client needs is a
bare-bones collection of classes that doesn't do anything terribly
fancy.  It can almost be described as consisting of wrappers for the
mechanism, container classes for mechanism specific elements
(like credential/name) and general purpose utility classes like the OID
class.  I see no point in defining these in terms of interfaces and
subjecting the application programmer to instantiating these
interfaces through a master class, or through querying system
properties and then calling Class.forName().newInstance().  For the
sake of ease of use the application programmer should just be able to
instantiate GSS-API classes with their constructors as shown below:

	Oid krb5Oid = new Oid(...); 
	GSSCredential cred = new GSSCredential(...);
	GSSContext context = new GSSContext(...);

I do see a good reason to define the GSSException class in terms of
an interface.  A GSSException object can be thrown from the mechanism
layer (draft-ietf-cat-gssv2-javabind-00.txt, section 4.10.2) and is
not something that the application programmer instantiates.  The
GSSException may be a Kerberos exception, for example, when dealing
with the Kerberos mechanism.  We want to allow this Kerberos exception
to trickle all the way to the top of the GSS stack as a GSSException
and at the same time not force the Kerberos mechanism level programmer
to derive from a GSS concrete class to avoid multiple inheritance
limitations in Java.  Therefore, it might be better to simply require
the Kerberos exception to implement a GSSException interface rather
than derive from a concrete class.

Mixing interfaces and concrete classes in this way allows, as I see it,
maximum flexibility to the mechanism level programmer and maximum ease of
use to the application level programmer.

The current Java bindings draft does assume that the GSS-API will be a two
layered solution, and that there will be some service provider interface
that will allow the lower layer to plug in underneath the veneer.  The
application programmer, meanwhile, interfaces only with the veneer and
that is the API that the Java bindings should focus on.  While it would be
nice to have a standard SPI for the mechanisms, that is not within the
scope of these bindings. 

I hope this addresses some of the concerns that people have had and look
forward to your feedback on this matter.

Regards,
Mayank

Jeffrey I. Schiller wrote:
> 
> [Not speaking ex-cathedra as Security co-AD]
> 
> My preference would be for interfaces and providers. I believe it isn't a good idea
> to depend on CLASSPATHs having a certain structure at run time.. Remember, at run
> time you are dealing with end-users, who may not have much clue! By using a class
> registration mechanism you ensure that if things are going to fail, they fail in a
> well understood fashion (Class not found, or "No suitable driver") rather then
> potentially instantiating a different GSSAPI mechanism then that which would
> intended.
> 
> It isn't that hard to use Interfaces.
> 
>                 -Jeff

Michael Smith wrote:
> 
> At 10:53 AM 12/9/98 -0500, you wrote:
> >[Not speaking ex-cathedra as Security co-AD]
> >
> >My preference would be for interfaces and providers.
> [....]
> >It isn't that hard to use Interfaces.
> 
> Another data point, possibly relevant: I've found
> in my own implementation efforts where I work that
> having the GSS-API consist of interfaces greatly
> increases my flexibility as a programmer, due to
> the prohibition in Java of multiple inheritance
> of classes (but of course no such restriction on
> interfaces). In my particular case, I needed to
> make some server-side CORBA objects which implemented
> the GSS-API. To make a long story short, the easiest
> way to do this was to have them extend some classes
> generated by the IDL compiler. But of course then
> they couldn't also extend GSS classes; whereas they
> could implement GSS interfaces.
> 
> --Michael Smith
>   [email-masked]

[email-masked] wrote:
> 
>      From an implementation point of view I definitely favor interfaces.
> 
>      From the applications point of view you need two things (at least)
> 
>      1) Description of how to use the classes (interfaces).
>      2) An instance of an object that supports those interfaces.
> 
>      1 is definitely within the scope of this document. The exact details
>      on how to get 2 may vary from implementation to implementation,
>      although having a standard interface to get an instance may be
>      helpful.
> 
> Concrete classes will probably force implementations to be more complicated than
> they need to be.
> 
>      Also in implementing GSSAPI in a COM (ugh) environment we found interfaces
> to provide more flexibility due to the similar restrictions it imposes on
> multiple inheritance.
> 
> -Joe
>

---

From: Michael Smith <[email-masked]>
Date: Thu, 04 Feb 1999 15:24:29 -0500

Many thanks to Mayank Upadhyay for a thoughtful and 
thought-provoking contribution to this topic. 

I have a few shoot-from-the-hip responses, which I may 
want to follow up with something more considered. 

Let me frame this response by observing that Mayank seems
to have the impression that under my approach, an implementation
of the GSS-API interfaces would have a one-to-one correspondence
with a mechanism -- hence his question: 

>program instantiating the new class. 

This wasn't my idea, though. My idea was that an implementation would 
include (of course) at least one mechanism, but might very well include
several -- as is in fact the case with our local project, somewhat 
inadequately documented at <http://www.panix.com/~jlefevre/GSS>. Thus 
an implementation could include SPNego as the default mechanism, say, 
and bootstrap from that into internally-generated object instances 
implementing whatever actual mechanism -- also included in that 
implementation -- ended up being negotiated by the SPNego mech. 

For that matter, the approach I propose is perfectly compatible 
with a "veneer" approach as sketched by Mayank: 

>the GSS-API should be treated as a veneer with a provider
>interface for mechanisms to fit underneath [....] 

The way I would envision this happening is that there would be 
an implementation of the GSS-API interfaces which would constitute 
the "veneer" machinery; the actual mechanisms included in it would 
then be those which had registered themselves with it using the 
"provider" interface Mayank mentions. Such a "provider" interface 
is of course necessary in the veneer approach, and so far as I know 
there hasn't been any work to date on what such an interface would 
look like. I don't think it would be trivial, though, and so while
I think that this approach, with the associated opportunities 
for dynamic updating and so on, is a very good one, I regard it 
as belonging to a later stage of work. The point I want to stress 
here is that my approach to the Java bindings does not in any way 
foreclose this undertaking, or even make it more difficult.  That
is: the "veneer" approach is merely a special case of my envisioned
multi-mechanism implementation, such that the mechanisms get folded
in at run time rather than compile time. 
 
>from other mechanisms to be added to it?  

Here again, it seems that the misunderstanding is that implementation equals 
mechanism. It's not _mechanisms_ that have implementations of GSS_Add_Cred;
it's _implementations_ (potentially, and indeed in general, multi-mechanism
implementations). For any such implementation, it makes perfect sense to 
add a credential for any mechanism it supports. 

>transparently to the application programmer.

Here I actually agree with Mayank: but the real nut to crack, as noted above,
is the design of the provider interface. If Mayank has ideas about that,
I for one would be most grateful if he'd write them up and get this ball 
rolling; because that's the really critical item for this approach. The 
question of whether the GSS-API looks to application code like interfaces
or concrete classes is orthogonal to the issue of the 
"two-layer" approach.

>I venture to
>layer GSS veneer to reference them.  

I hope Mayank won't be offended if I observe that this reminds me
of the old joke about the economist marooned on a desert island with 
a huge stockpile of canned food but nothing to open the cans with. His 
solution? "Assume a can opener...."

The "can opener" that Mayank is assuming is the "SPI". I don't know to 
what extent Mayank is articulating a strategy that Sun has decided on; 
allow me to muse a bit, just hypothetically. If Sun wants to define and 
build the concrete "veneer" classes implementing GSS, and include them 
in the core classes of Java, say, and define the SPI while they're at 
it, this would be fine with me. Java is theirs, after all. I suspect that 
both the class mappings visible to applications, and the SPI, might be 
the better for being discussed in this WG rather than dashed off by Sun 
without the broader discussion; but even so, I'm sure they'd do a good 
job. But one can't intelligently discuss a proposal for this "two-decker"
approach unless the SPI forms part of it. 

Finally, at the risk of repeating myself, let me state that I like the 
"two-decker" or "veneer" approach, with SPI, too; I'm not arguing against 
it. Even with this approach, if and when it becomes possible, though, I 
would suggest that having the GSS API be defined by interfaces rather than 
concrete classes provides an extra degree of freedom for implementers which
would be quite useful to have and imposes no costs that I can see. It also 
makes it possible for us to implement actual mechanisms and sets of mechanisms
and starting using them, in Java, under GSS, without having to wait for 
the "SPI" to be defined and the "veneer" core classes to be written and shipped.
We can then take the time required to do these latter jobs with due 
consideration. 

--Michael Smith
  [email-masked]

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Mike Eisler <[email-masked]>
Date: Fri, 5 Feb 1999 16:48:18 -0800 (PST)

In your proposal, I'm curious if it is possible to write a java program that
doesn't have any explicit references in the source code to the GSS-API
mechanism that implements the interface? Stated another way, can I write
program such that it accepts as input a mechanism OID, etc. and then creates a
context with that mechanism?

> what extent Mayank is articulating a strategy that Sun has decided on;

FYI, Mayank protoyped the specification and it includes an SPI.

> it, this would be fine with me.

Interesting set of requirements.  Perhaps I haven't subscribed to this alias
long enough, but I don't recall someone ever stating that as long as John
Wray's employer defined an SPI, draft-ietf-cat-gssv2-cbind-XX.txt would be
fine with him.

>                                ... Java is theirs, after all. I suspect that

This has come up twice now.

Java is Sun's.

Nonetheless, the affiliation Mayank and I have must not have any bearing on
what the WG decides with respect todraft-ietf-cat-gssv2-javabind-00.txt. Don't
intepret our accession of this internet draft as an agreement by Sun to
implement this in a future JDK or any product. By the same token, don't
interpret our disagreement with the consensus of the WG as a refusal by Sun to
implement this. Ignore the ".sun.com" in our e-mail addresses when considering
our opinions on this internet-draft.

> approach unless the SPI forms part of it.

Why is it that we assume the can opener for C and not for Java?

        -mre

---

From: Michael Smith <[email-masked]>
Date: Sat, 06 Feb 1999 15:22:40 -0500

At 09:18 PM 2/5/99 -0800, Mike Eisler <[email-masked]>
wrote:
>> 
>> [quoting my earlier] "Implementation" does not equal 
>> "mechanism" -- in C, or Java, or perl or whatever. 
>
>I don't understand the above sentence. Anyway ...
>

Hmmm. Well, my idea of an "implementation" of the Java GSS-API 
interfaces is a group of classes -- say, a package -- which collectively
implement one or several mechanisms. If an application wants to request, say,
credentials for a given mechanism, it just passes in the appropriate OID 
and (assuming the requested mechnism is one of those implemented by the 
package in question) gets back a reference to some class instance 
that implements GSSCredential and contains the right behavior for that 
mechanism. This is no different from multi-mechanism implementations
in C or any other language. 

>What would one have to do to the existing internet-draft to use your proposal?

My own version of the interface (see <http://www.panix.com/~jlefevre/GSS>)
allocates the functions a bit differently from the draft. But that's 
not very consequential; the only important point of divergence
between my proposal and the I-D is that I think the definition 
ought to consist of interfaces rather than classes. (Except for 
GSSException, which has to be a class because exceptions have to extend
java.lang.Exception, don't they?) 

>Solaris7's C-bindings GSS-API has an SPI, only it's not documented. There's
>some semblance of an SPI in the MIT Kerberos 1.0 implementation of the
>C-bindings GSS-API. Microsoft has its Security Service Provider Interface,
>which by its name implies an SPI for a C-bindings GSS-API. 
>
>I can't offer up the the Java or C SPI that my employer has because it's not
>mine to offer up. 

Well, that's understandable. But still: if we want to tie the Java language 
binding of GSS to the notion of concrete classes that act as a "veneer"
(Mayank's term) to providers, then to my way of thinking it doesn't 
make sense to do that without also defining an SPI. Now I believe that 
there was once some talk in the WG of defining such an SPI in a language
independent way, so that it would be the provider-side analogue of GSS;
this doesn't seem to have gotten very far, but it does seem to me that that's 
the right way to go; and that it's a bit bass-ackwards to do it for one 
language without having done it language-independent first. -- Although 
perhaps one might argue that the low-level character of an SPI makes it 
sensible to define a different one for each language, so as to take 
advantage of, say, different performance properties of different 
languages. Was this your line of thinking? 

--Michael Smith
  [email-masked]