Subject: Objects as tokens (was: GSSAPI issues...)

From: Michael Smith <[email-masked]>
Date: Wed, 27 Oct 1999 11:45:27 -0500

At 02:54 PM 10/26/99 -0700, Jack Kabat <[email-masked]> wrote:

>What ever is passed into the JGSS to represent tokens has
>to have a clear API on how to read/write data to it.
>Object class does not have this.

I see that I've given both Jack and Joe the same mistaken 
impression of what I had in mind; obviously I expressed 
myself badly. May I ask the list's indulgence to re-state
my suggestion in a (hopefully) clearer way? 

My idea was simply to TYPE (forgive the caps) the token 
parameters, in the interfaces, as Object, solely so as 
not to constrain what kind of objects could, in particular 
cases, be used as tokens. This was not intended to 
suggest that any mechanism could take any kind of object, 
or that mechanisms would have to restrict themselves to
the exiguous repertoire of methods that Object has, in 
processing tokens. Rather, my idea was that particular
mechanisms (or mech implementations, MIs) might well want 
to support, as tokens, kinds of objects above and beyond
byte arrays. The kinds of objects they'd want to support 
would depend, perhaps, on the nature of the security protocol
and/or the application protocol and on the repertoire of 
object representations associated with these. It wouldn't 
be the same list for every mechanism, or MI, and many 
mechanisms, no doubt, would find that byte-array filled 
all the requirements. 

An MI's implementation of one of these Object-typed 
methods would begin by finding out exactly what _kind_
of object was passed in as a token, and then going off
to code written to process that particular kind of object, 
using whatever methods that object supports. If it got 
an object that it didn't support as a token, it would 
throw an exception -- precisely as it would do if it 
got a syntactically malformed token in a byte array. 

How would applications know what kinds of objects they 
could use as tokens? Here, we added methods -- 

Class[] getContextTokenClasses()
  and
Class[] getMessageTokenClasses()

-- to advertise what the mechanisms could handle. 

Here's some code fragments, adapted from the stuff 
we're using here:

/* 
From a mechanism implementation  
Heavily edited and not guaranteed to compile
*/

/**
*  Utility function to tell callers what kinds of objects are acceptable
*  as context-establishment tokens. Note that byte [] is always acceptable. 
*
*/
public Class[] getContextTokenClasses()
{
Class accepts[] = new Class[1] ;
try
   {
   accepts [0] =
      Class.forName("javax.servlet.http.HttpServletRequest");
   }
catch (Exception e)
   {
   Class [] nullaccepts = {};
   return nullaccepts;
   }
return accepts;
}

/* 
I'm reluctant to show you any real mechanism 
code, it's such a dog's breakfast, but here's 
the general appearance of the logic that branches
on token type:
*/

public void accept(Object token) throws GSSException
{
byte[] b = {1,2,3};
Class bclass = b.getClass();
Class sclass;
try
   {
   sclass =
      Class.forName("javax.servlet.http.HttpServletRequest");
   }
catch (Exception e)
   {
   sclass = null;
   }
if ((token.getClass()).equals(bclass))
   {
   // Do something with the byte array
   return;
   }
if ((token.getClass()).equals(sclass))
   {
   // Do something with the ServletRequest
   return;
   }
throw new GSSException
   ( new BasicGSSStatus
      (GSSStatus.GSS_S_BAD_TOKEN,
      (short)0, // Revisit this and signal more detail?
      (short)0,
      null)
   );

} 

--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: Wed, 27 Oct 1999 09:37:30 -0700 (PDT)

> processing tokens.

Would a peer, bound to the C-bindings GSS-API be able to accept and process
these tokens?

	-mre