Subject: Proposed changes to draft-ietf-cat-gssv2-javabind-01.txt (fwd)

From: Mayank Upadhyay <[email-masked]>
Date: Tue, 25 May 1999 18:01:20 -0700 (PDT)

We would like to complete all changes to this draft next week as far as
the introduction of interfaces and multiple top level GSS-API providers
go. If you wish to review the proposal and send us some feedback you can
find the proposal, sample apps, and a class diagram online at: 

http://playground.sun.com/~mdu/

We look forward to your response.

Regards,
Mayank Upadhyay
Jack Kabat

---

From: [email-masked]
Date: Wed, 26 May 1999 18:09:23 -0700

First, I prefer the IGSS* naming convention over GSS*Int.  It seems 
     more standard, but then I may have lived in C++ (and Microsoft) land 
     far too long. 
     
     I'm worried that we cannot meet both the applet and applications needs 
     with one method of instantiating classes. We need to draw a line 
     between "stand alone" GSSAPI implementations and "system" GSSAPI 
     implementations.  I use "stand alone" to refer to a GSSAPI provider 
     that provides a complete implementation for a mechanism(s) based on 
     the interfaces provided (typically done within an applet).  A "system" 
     provider sits under a system wide GSSAPI implementation that provides 
     access to multiple mechanisms (typically within in application or 
     server).   Currently the GSSManager concrete class instantiates both 
     types.  I am against this for the following reasons.
     
     -  An applet may not be able to set the necessary system provider 
     properties. 
     -  It requires the applet to have access to a common implementation of 
     GSSManager.
     -  It encourages mixing of objects between providers.  Having a 
     GSSManager class that instantiates multiple providers suggests that 
     one might be aware of another.
     -  It adds more weight to the applet code.
     -  A provider management API is currently not specified for GSSAPI.
     
     I propose that the applet writer must know the name of the GSSFactory 
     class and instantiate it directly for an "stand alone" provider.
     
     The "system" and "stand alone" methods differ in how classes are 
     instantiated and where the GSSManager functionality lies. Reorganizing 
     the document would help separate the details of implementation from 
     the GSSAPI interfaces.
     
     Separate the document into two sections. The first defines the set of 
     interfaces and common classes adding an IGSSManager interface (or, if 
     you like GSSManagerInt  see sample code at the end).    The second 
     specifies two implementation models, the "stand alone" model oriented 
     towards applets and the "system" model oriented towards applications.  
     
     Stand Alone Model
     -----------------
     In the stand alone model the  implementation provider provides a class 
     that implements GSSFactory and IGSSManager.  The application must know 
     the name of the provider class that implements GSSFactory.  The 
     application uses the GSSFactory interface to get instances of the 
     GSSContext, GSSCredential, and GSSName classes as needed.  Using 
     different implementations requires instantiating different classes, 
     this reinforces the fact that different implementations probably will 
     not co-operate to share tokens.  Here the GSSManager functionality is 
     covered by the same class that implements GSSFactory.

     System Model
     -----------------
     In the "system" model there is a well known GSSManager class that 
     implements the IGSSManager interface. as well as well known 
     GSSCredential, GSSName and GSSContext classes that implement their 
     respective interfaces.  In this model there may be co-operation 
     between mechanisms so that tokens can be created for and used in 
     multiple mechanisms.

     I am pushing for two different models because applets and applications 
     need different things.  In the applet world the browser restricts 
     access to system properties and functions.  Browser support limits how 
     quickly new features are implemented.  Additionally, the smaller the 
     applet the better.  An application, on the other hand, can demand 
     better VM support, have huge code size, and access anything in the 
     system it wants to.  I would probably not be able to use the proposed 
     changes in an applet.  

     -Joe

     Code Samples
     --------------
     
     New interfaces:
     /**
      * IGSSManager is a interface to provide information about mechanism   
      * implemented in the specific provider
      *
      */
      public interface IGSSManager {
        public Oid[] getMechs();
             public Oid[] getNamesForMech(Oid mech) throws GSSException;
             public Oid[] getMechsForName(Oid nameType);
             public Oid getDefaultMech();
      }

     /**
      * GSSFactory is the main interface that a provider implements. 
      * The caller must know the name of the class that implements this     
      * interface
      */
     public interface GSSFactory {
        // Factory methods      
        public GSSContextInt    getContext();
        public GSSCredentialInt getCredential();        
        public GSSNameInt       getName();
     
     }
     
     /** an stand alone GSSAPI provider would implement both of the above   
      *  interfaces
     
     public class GSSStandAloneProvider implements IGSSManager, GSSFactory{
     
     ...
     
     }

______________________________ Reply Separator _________________________________
Subject: Proposed changes to draft-ietf-cat-gssv2-javabind-01.txt (
Author:  mdu ([email-masked]) at internet
Date:    5/25/99 6:01 PM

     
     
Regards,
Mayank Upadhyay
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]