Subject: GSS-API Java Bindings: Changes in new draft

From: Mayank Upadhyay <[email-masked]>
Date: Fri, 22 Oct 1999 17:44:49 -0700 (PDT)

Here is the list of changes that Jack and I have made to the Java bindings
for GSS-API in draft-ietf-cat-gssv2-javabind-03.txt.

I'll try to have updated javadocs out on http://playground.sun.com/~mdu/
over the weekend. 

-Mayank

===================================================================

(1) Added MessageProp.getMinorStatus() and 
MessageProp.getMinorString().

We should be able to return a minor status code from per-message
calls even if no exception is thrown. For example, this might be
needed if unwrap sees an out of sequence token, which is informatory
but not a fatal error for per-message calls.

(2) GSSName does not extend the java.security.Principal 
interface anymore.

Not all web-browser based JRE's have the java.security.Principal
interface defined in them. We have removed this to ensure the API can
be used in the browser environment.

(3) The package name org.ietf.jgss is all lower case.

This is the convention, although the org.omg packages for CORBA are an
aberration. This makes it possible for reader's to distinguish package
names from class names (that begin with upper-case) without knowing
anything else.

(4) Removed concrete classes GSSName, GSSCredential and GSSContext
that were adding no functionality but simply providing constructors to
create implementations of IGSSName, IGSSCredential and IGSSCredential
and delegating to those implementations. The GSSManager class still
provides factory methods to create implementations of those
IGSS* interfaces.

Using the simple factory methods in GSSManager eliminates any advantage
of having the concrete class wrappers. The API is leaner without any
sacrifice in functionality/operating paradigm.

Renamed IGSSName to GSSName, IGSSCredential to GSSCredential, and
IGSSContext to GSSContext since those names were available and are
more appropriate.

(5) Removed the details of how to lookup and query Security Providers'
deferring them to the service provider interface (SPI) specification.

This approach assumes that the GSS implementation may or may not be a
modular layer that can be extended with providers to add support for more
mechanisms.  For GSS implementations that can do so, there is a one call
(setProvider)  that allows an application to indicate a preferred provider
for a particular mechanism. The GSS-API does not have to honor this
request and has a way to indicate this. 

We wish to be very clear that you do not need to use providers, but
the API has a method to optionally allow this.

(6) Removed the GSSFactory interface

Left it upto the SPI to define provider based GSSFactory's. The
GSSManger class provides factory methods to obtain instances of the
interfaces GSSName, GSSCredential, and GSSContext at the top
level. Those may or may not internally use any SPI level GSSFactory
obtained from providers.

An application that wants to use its own custom complete GSS
implementation can simply subclass GSSManager from a standard GSS
package.

This hides any SPI related functionality in the GSS layer. Mechanism
specific factories logically belong in the layer below the GSS.
Applications using the GSS-API should be isolated from the SPI layer. 

(7) Changed static methods in GSSManger to non-static

If any preferences are set through static methods, they influence all
code running in the same JVM. This is not an acceptable situation for
applets in the same browser. Also, applications can now instantiate
multiple GSSManager's and have different provider preferences on each
of them. Some of these GSSManager's may even be from the applications
own custom GSS implementation.

(8) Modified sample code to match the changes in the API.

===================================================================

==========================================================================
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: Joe Salowey <[email-masked]>
Date: Mon, 25 Oct 1999 16:14:44 -0700

I'd rather not see any more concrete classes in the API than we need to.  A
factory interface provides the capability of allowing the programmer to do
most of what needs to be done in a standard way without forcing a particular
implementation.  The GSSManager class forces a particular implementation (it
forces you to have a concrete class org.ietf.gssapi.GSSManager and it also
assumes a provider infrastructure).  I would rather see an interface here
than a concrete class to get these tasks done. The interface would consist
of 

createName
createCredential
createContext
getMechs
getNamesForMech
getMechsForName 

I'm not sure much is gained by specifying this as a concrete class and I
think flexibility is lost.  The factory interface provides value for
developers trying to use GSSAPI without constraining the underlying
implementation.

Joe

> -----Original Message-----
> From: Mayank Upadhyay [mailto:[email-masked]]
> Sent: Friday, October 22, 1999 5:45 PM
> To: [email-masked]
> Cc: Jack Kabat
> Subject: GSS-API Java Bindings: Changes in new draft

... Text Removed

---

From: Jack Kabat <[email-masked]>
Date: Thu, 28 Oct 1999 14:45:42 -0700

Hello,

Here are some more comments about the old
interface vs concrete class discussion....

Interfaces are appropriate in many environments and I
think there is a place for them in our specification.
This is why we have changed the GSSName, GSSCredential
and GSSContext to use them. But I don't think they are
always appropriate.

Having concrete classes gives the following advantage
(and yes Michael, it is related to constructors). When
specified as concrete class in our draft, all implementation
must provide a GSSManager class. Then, all applications
can safely instantiate a GSSManager object in their
implementation:	GSSManager mgr = new GSSManager();

If we take the route of interfaces, each GSS implementation
will implement a GSSManager behaviour in some object, but
how will the applications know what class to instantiate to
get this behaviour?

For example, my implementation will have class X implement
GSSManager interface, while Michael's will have class Y
implement the interface. The application code now needs to
determine, in some out of band way, which class to create
to get the GSSManager functionality. If I switch between
implementation, I have to change the class I create!

This is also the motivation behind having a GSSFactory/GSSManger
class in the first place. Otherwise we could just require the
user to instantiate the other interfaces directly. Instead, we
provide GSSManager to have the logic to know which class it
should create for each of the interfaces.

I'm also skeptical about the loss of flexibility argument w.r.t
to the GSSManager class. I think this was a fair argument when
talking about the more general classes of GSSContext, Credential
and Name, but does not have as much weight here.

I think satisfying the interoperability requirement and ease
of use by the applications far outweighs any other possible
loss in flexibility.

Regards,

Jack

> From: Joe Salowey [mailto:[email-masked]]
> Sent: Monday, October 25, 1999 4:15 PM
> Subject: RE: GSS-API Java Bindings: Changes in new draft
> 
> 
>

---

From: Joe Salowey <[email-masked]>
Date: Thu, 28 Oct 1999 15:44:37 -0700

comments added in text below.

> From: Jack Kabat [mailto:[email-masked]]
> Sent: Thursday, October 28, 1999 2:46 PM
> To: Joe Salowey
> Cc: [email-masked]

(... some lines removed)

> how will the applications know what class to instantiate to

This is part of the documentation that comes with the particular GSSAPI
implementation.

> implementation, I have to change the class I create!

This is true, but that may be all you have to do, and depending on the needs
of your application it may not even require a code change.  How does one
write a provider for GSSManager? You need an SPI. If GSSManager is concrete
and required then the high level bindings are tied to the SPI.

> should create for each of the interfaces.

What happens if there is a GSSManager in the class search path on the local
system, and a different GSSManager is being downloaded in the code of an
applet?  In java 1.1 the applet class will not get run (and the applet will
not get the functionality it requires). Java 2 has more of a chance of
working, but I have not tested it out yet. 

> and Name, but does not have as much weight here.

The flexibility is in the capability to deal with multiple implementations
of Java GSSAPI.

> of use by the applications far outweighs any other possible

The interoperability requirements are not satisfied.  How do Java 1.1 (yes
people still use java 1.1 and even 1.02) applets make sure the get the right
GSSManager class?  How does one write a mechanism to fit in the GSSManager
provider framework (where is the SPI)?  I would like to see a document which
essentially contains everything you need to code a mechanism and use the
interfaces.  Which Java GSS implementation you use is up to the application
developer (unless there is only one implementation). Interface code should
be provided as well as code for the simple container classes (such as OID,
MessageProps, ChannelBindings).  Right now the GSSManager class is
undefined.  In order to define it you need to specify an SPI to make the
document complete.  This means the SPI and high level API must progress
together.
 
Thanks for listening,

Joe