Subject: Lessons of the SPI, re Java bindings

From: Michael Smith <[email-masked]>
Date: Fri, 14 May 1999 11:43:38 -0400

I've been reading with great interest the long note from 
Mayank describing the changes that he and Jack have made 
to their Java bindings proposal. One issue strikes me right 
away, which I think deserves a discussion of its own; I'll 
reserve comments on other aspects of the proposal until I've 
had a chance to study it further. 

The Minneapolis discussion of a "service provider interface"
by which GSS mechanism providers could be called by a shim 
layer fired my imagination, and I wrote up a proposal for 
such an SPI in the form of an I-D, which can be found 
at <http://www.ietf.org/internet-drafts/draft-ietf-cat-
gssv2-javabind-spi-01.txt> (sorry about the line break).

What I found was that while such an SPI strongly resembles
GSS itself, it can't be quite identical. The GSS mapping 
which I took as my point of departure was the one we did 
here at TIAA-CREF. That mapping, unsurprisingly, provided 
four major interfaces -- GSSName, GSSImplementation, 
GSSCredential, and GSSSecurityContext -- and a few minor 
ones (Implementation is, roughly speaking, the "factory" 
interface.) Now of these four, three -- Name, Credential, 
and Implementation -- are multi-mechanism. The fourth 
(Context) is not; at the point when a context is created, 
a mechanism must be chosen, and each context uses a single 
mechanism. (This is the reason why, in abstract GSS, the 
context initialization call contains so many parameters -- 
any or all of them may be relevant to the choice of a 
mechanism. But I'm getting ahead of myself here.) 

What I found it necessary to do in my SPI was define 
modified, single-mechanism versions of the Name, Credential, 
and Implementation interfaces, and call them ProviderName,
ProviderCredential, and ProviderImplementation. These still 
strongly resemble their parents but have slightly different 
repertoires of methods and slightly different signatures for 
some of the methods they share with the parents. 

However, I found it was unnecessary, and, as I thought, 
undesirable, to define a similar ProviderContext. There's 
no reason why a provider can't implement GSSSecurityContext
directly, since a context is always single-mechanism; and 
for reasons of performance and simplicity, it seemed wrong 
to interpose a do-nothing shim layer between the mechanism's
version of Context and the one the user sees. 

Now comes the rub. My original interfaces spec, like Jack
Kabat's original classes spec, eliminated the long parameter
list to the context-creation call (i.e., the mapping of 
the null-handle version of Init_security_context) in favor 
of a simple getContext() factory method and a bunch of 
"set...()" methods (of the context itself) which would be 
called after the context had been obtained. (Jack's, of
course, used a constructor rather than a factory method, 
but the idea is the same.)

Y'all see the problem, right? If the "shim" has a number of 
mechanisms registered with it, and its factory method to create
a context is called, how does it choose the mechanism, since 
it doesn't have all the parameters available that may be 
relevant to a choice? 

After some head-scratching on my part, I resolved on a 
solution that required re-organizing the GSS mapping itself 
slightly. I defined a new interface, with the slightly 
whimsical name of GSSContextHatchery (I'm getting tired of 
all these Factories, and some agricultural scenery would
provide a little variety, I thought). The GSSImplementation
interface -- the main "factory" -- now has a method, 
GSSContextHatchery getContextHatchery(). GSSHatchery in 
turn has a number of methods to set all the parameters  -- 
privacy, mutuality, anonymity, etc. -- and defined defaults 
for those not explicity set, and two methods, 
GSSSecurityContext bindForInit(<acceptor target name>) and 
GSSSecurityContext bindForAccept(<input token>). 
The idea is that the GSSHatchery implementation of the shim 
will have either explicitly set or defaulted values for 
all the parameters, and can then choose among the registered
providers on that basis, calling a factory method of the 
chosen provider's GSSProviderImplementation to return 
that provider's GSSSecurityContext implementation. 
(Note that Hatcheries are reusable, so you don't have 
to get a new one every time you get a new context.)

The disadvantages of this scheme are that it defines 
another interface and requires another initialization 
step of the application programmer. Other approaches 
are of course possible: 

1) The factory method that produces a context could take 
all the parameters originally defined for abstract GSS. 
Drawback: unattractive and un-Javaish. 

2) The provider and the shim could implement different
context interfaces, and the shim's could wrapper the 
provider's. The shim's would provide all the "set...()"
methods for the context establishment parameters, and 
the provider's could have the ugly long paramater list.
Disadvantage: an interposed layer of code
providing no benefit on the vast majority of context 
calls (I assume that in general, calls to wrap() and
unwrap(), getMIC() and verifyMIC() will greatly outnumber
initialization calls; and the shim code, of course, 
would only have a substantial function at initialization 
time.)

My revised interfaces spec is available as an I-D. 
I notice that for some reason it's no longer on the 
CAT page on the IETF Web site; I'll resubmit it, which 
is probably a good idea anyway since errors have 
been noticed by readers since it was first submitted. These
will be corrected in the revised version, which will be 
called <draft-ietf-cat-gssv2-javabind-ifs-01.txt>. 
So the full URL will presumably be 
<http://www.ietf.org/internet-drafts/draft-ietf-cat-
gssv2-javabind-ifs-01.txt> (sorry again about the line 
break). If you can't wait for it to appear in the I-D
repository, e-mail me and I'll send you a copy -- it's 
pretty short. 

Javadoc for our implementation is readable at 
<http://www.panix.com/~jlefevre/GSS>. 

I attach a short code fragment illustrating 
how we use this GSS mapping. This is for a Web application
which uses DAA authentication on the Web and obtains a 
RACF passticket (yes, RACF) for mainframe operations 
on the back end. 

import org.tiaa_cref.GSS.*;

---

From: "Jack Kabat" <[email-masked]>
Date: Wed, 19 May 1999 10:46:51 -0700

Hello Michael and Everyone,

Let me start with some general comments about your note, followed by more
specific comments throughout your e-mail.

I think if we hope to be able to progress the Java GSS bindings forward we
need to be evaluating its scope with respect to RFC 2078 and not attach
baggage of the SPI approach. I see the following reasons for this:

1) SPI approach is just one of the ways one can implement a GSS-API package.
This applies as much to the C version as to the Java version. It is
reasonable to see implementers of the Java GSS not using the SPI approach
and still having a fully functional Java implementation.

2) I have not yet seen the interest within the group for the SPI approach. I
would like to ask the group if the interest is any greater then just
curiosity?

3) We should revisit the scope of the Java bindings. It was started as just
the language bindings for RFC 2078, and I think we are now beginning to make
it much more then just that.

more comments follow within Michael's e-mail....

Regards,

Jack

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Michael Smith
>Sent: Friday, May 14, 1999 8:44 AM
>To: [email-masked]
>Subject: Lessons of the SPI, re Java bindings
>
>

The actual mechanism specific context can be created during an accept or
init. At that point we do have all the required parameters. Also, if needed
the GSS layer can peek inside the generic encapsulation of GSS messages to
determine the intended mechanism to instantiate. By the time the user calls
init, they should have already set all the context options. On accept, these
options are return values to the user from the received context token.

The prototype I was involved writing at SUN used this approach and we found
it to work well in a multi-mechanism situation. We always had enough
information to determine what mechanism to call.

Can you be more specific about what parameters you are missing?

>provide a little variety, I thought). The GSSImplementation

I appreciate your creativity - Hatchery is a clever name. But I think we
should stick with de-facto naming conventions that are familiar in the Java
environment. So I would prefer the old naming convention of factories. This
is not just because I'm a city folk :-)

>would only have a substantial function at initialization

I don't see the big performance problem that you describe with approach 2
and feel this is the most straight forward way to solve this problem. At
most, the JGSS layer will be just a pass through to the mechanism. This will
have the benefit of isolating the end-user (our customer) from the intricate
details of the SPI interface which can be different then the JGSS layer (as
you mentioned yourself). And again, I don't think it is fair to assume that
everyone will choose the SPI approach to implement their JGSS. Please see
the other points I have at the start of this mail.

>import org.tiaa_cref.GSS.*;

==========================================================================
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]