Subject: JGSS bindings

From: "Jack Kabat" <[email-masked]>
Date: Mon, 8 Feb 1999 10:14:46 -0800

Hello All,

Glad to see the high level of interest in the Java GSS-API bindings. Thank
you all for the fruitful contributions to this topic.

First, some comments regarding the "Veneer or not" discussion. In my
opinion we are getting into the implementation details of the specification.
We must strive to provide an API which allows both approaches but I would
consider these just that - different approaches for implementing the API and
would leave it to the implementations to decide which to select. I have seen
C versions of the GSS-API that have selected either of these to solve this
problem. But again this was an implementation decision and was not specified
anywhere in the language bindings. Clearly without defining the SPI
interfaces in the specification we can't mandate that as the preferred
solution and I think we all agree that the SPI interface definition is
outside the specification of the Java language bindings.

Next, I think the discussion has moved away from the main issue raised
by Michael. As I remember it, Michael wanted to have a central class
which the users of the GSS package would use to create instances of the
other GSS objects making up the API.  The reason for this was to shelter
the applications from knowing the full class name of the other classes
(only the main creator class would need to be known).  As a consequence
the other objects were defined in terms of interfaces rather then classes. I
am still not convinced that having one central class for creating other GSS
objects accomplished the goal of hiding full path of classes. After all, the
main class must somehow be referenced.  Also, I can see applications wanting
to explicitly specify the class to ensure they are loading the desired
GSS-API implementation.

Michael, I think it would be helpful if you could provide some sample
application code showing the usage of your API and how it solves the
above problem.

A separate issue that has arisen is related to using Interfaces vs concrete
classes in the specification. I am interested in hearing some more input on
this issue. I recall Michael sharing some implementation notes which favored
the use of interfaces.

Regards,

Jack Kabat

==========================================================================
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: Michael Smith <[email-masked]>
Date: Wed, 10 Feb 1999 00:34:43 -0500

At 12:47 PM 2/9/99 -0800, Mayank Upadhyay <[email-masked]> wrote:

>Michael, if you wouldn't mind could you please use the current Java
>bindings, convert them to interfaces if you like, and post a sketch of a
>sample server program that can accept connections that might need
>different mechanisms. You may add system properties or factory classes as
>you please.

I'm at a bit of a loss as to just what's being requested here, and
what it is that needs to be elucidated. 

Any "server program" that accepts connections (and, more importantly, 
contexts) and may need to use multiple mechanisms across GSS-API 
has to do one of two things: 

1) determine which mechanism is to be used by examining the context
establishment token, or by some other external means (e.g. port number),
or 

2) just give the context establishment token 
to the "default mechanism" and hope for the best. 

(Of course, the "default mechanism" may be some kind of polyglot or
may even be able to negotiate a mutually satisfying mechanism with 
the requester, as is the case with SPNego.) I can't for the life of 
me see what any of this has to do with the question of whether the API is 
classes or interfaces, which is still (isn't it?) the topic at hand. 

The source tree for an early version of our (very minimal) multi-mechanism
implementation can be browsed (please, be kind) at 
<http://www.panix.com/~jlefevre/GSS/org/tiaa_cref/DCAAF1_0/DAAClient/>. 
This doesn't quite satisfy all of Mayank's requirements, in the sense
of _selecting_ a mechanism based on what it gets; what it does do 
is establish a context based on a DAA-authenticated HTTP request, 
and then parlay that into a context which will issue RACF passtickets
to be used in back-end requests to a mainframe. Thus we have two 
very minimal "mechanisms", the DAA one and the RACF one. 

I'm afraid I don't have time to spare to produce other "sample
implementations," but if there's anything unclear about the 
existing one, I'll try to resolve any questions that come up.

If Mayank is asking, how does an application find that crucial
initial reference to the implementing class? -- well, that remains
an open question. Our solution for the time being is to find its
name from a system property, as I mentioned earlier. Now if we 
(the WG, or the IETF, or whoever) want to define a "standard" 
way to do this, so much the better. Mayank's solution is essentially
to have a well-known class name that implements the "veneer". 
Which is great, except that it presupposes a (still completely 
undefined) "service provider interface" to the "veneer," and until
that's available, we're without a java GSS API -- unless indeed 
we write classes that impersonate org.ietf.cat.GSS, or whatever. 
This doesn't seem very satisfactory to me.  

--Michael Smith
  [email-masked]

---

From: Ram Marti <[email-masked]>
Date: Wed, 10 Feb 1999 10:10:31 -0800 (PST)

> X-Sender: [email-masked]
> Mime-Version: 1.0
> Date: Wed, 10 Feb 1999 00:34:43 -0500
> To: Mayank Upadhyay <mdu@Eng>
> From: Michael Smith <[email-masked]>
> Subject: Re: JGSS bindings
> Cc: [email-masked]
> 

Currently I don't think there is an exposed public GSS API to determine the 
mechanism  from the token. This is done by the GSSAPI Implementation without 
application involvement and it seems to be better to keep it that way; otherwise 
application development will get more complex. As such GSSAPI is not the easiest 
API around to use.