Re: GSS-API V2: C# Bindings

"Juan Carlos Luciani" <jluciani@novell.com> Tue, 31 January 2006 16:26 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yLF-0003DV-Ta; Tue, 31 Jan 2006 11:26:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yL9-0003Bo-Cm for kitten@megatron.ietf.org; Tue, 31 Jan 2006 11:26:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03397 for <kitten@ietf.org>; Tue, 31 Jan 2006 11:25:02 -0500 (EST)
Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3yVy-0001io-V0 for kitten@ietf.org; Tue, 31 Jan 2006 11:37:59 -0500
Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Tue, 31 Jan 2006 09:26:22 -0700
Message-Id: <43DF2D2E.365D.009A.0@novell.com>
X-Mailer: Novell GroupWise Internet Agent 7.0
Date: Tue, 31 Jan 2006 09:26:06 -0700
From: Juan Carlos Luciani <jluciani@novell.com>
To: Horst Reiterer <horst.reiterer@mind-breeze.com>
References: <43DD65A8.10200@mind-breeze.com>
In-Reply-To: <43DD65A8.10200@mind-breeze.com>
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8
Cc: kitten@ietf.org
Subject: Re: GSS-API V2: C# Bindings
X-BeenThere: kitten@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kitten>
List-Post: <mailto:kitten@lists.ietf.org>
List-Help: <mailto:kitten-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1964150486=="
Sender: kitten-bounces@lists.ietf.org
Errors-To: kitten-bounces@lists.ietf.org

Hi Horst, 

After reading the .NET naming guidelines, I agree with your assessment
that the bindings should use Pascal casing for methods, properties as
well as constant value names. I also agree that classes that need to
provide explicit control to developers for when native resources are
released should implement the IDisposable interface to be compatible
with the .NET Framework's Dispose pattern. 

I will update the draft with the naming changes and with the changes to
the GSSCredential and GSSContext classes indicating that they implement
the IDisposable interface. 

Please let me know of any other issues that you may see. 

Thanks you very much for your help, 

Juan Carlos Luciani

>>> Horst Reiterer <horst.reiterer@mind-breeze.com> 01/29/06 6:02 pm >>>
Juan Carlos,

I am working on integrating Kerberos authentication into a Mono-based
application (possibly the Mono Framework implementation itself if I can
find the time) so that native Kerberos clients can interoperate with
Mono-based services. While starting the implementation, I've come across
your GSS-API C# bindings draft:

 
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-csharp-bindings-00.txt

I'm glad that bindings already exist or are being worked on at the
moment. In the introduction, you mentioned that one of the design goals
was to emulate the Java bindings specified in RFC 2853 as much as
possible while still taking advantage of C# features such as
Properties. I fully agree here! I must say however that the bindings
IMHO follow the original too closely in some respects. Let me mention
two concrete examples:

  a) byte[] acceptSecContext(byte[] inTok,
                            int offset,
                            int len);

     Methods, properties as well as constant values (e.g. NO_CONTEXT)
violate the .NET Framework coding guidelines as defined by Microsoft
(methods properties and constant values should use Pascal casing). For a
C# developer, it is very inconvenient to work with a library that does
not follow the platform's naming conventions for example. Modifying the
bindings to follow the guidelines would IMHO make it's interface
significantly more intuitive.

     Was there a particular reason why you've chosen to follow the Java
naming conventions here?

     References:
     http://msdn.microsoft.com/library/default.asp?url=
     /library/en-us/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp

  b) void dispose();

     In my opinion, this is a very serious issue because this disposal
facility simply bypasses the .NET Framework's Dispose pattern and thus
does not allow developers to handle objects with native resources
accordingly. As a .NET Framework developer, I would expect the following
(modified sample taken from the draft) to work:

     // ...
     GSSCredential cred = mgr.createCredential(name,
                            GSSCredentialUsage.ACCEPT_ONLY);

     using (cred) {
       Oid[] mechs = cred.getMechs();
       if (mechs != null) {
         for (int i = 0; i < mechs.length; i++)
           Console.WriteLine(mechs[i].ToString());
       }
     }

     Unfortunately, it can't because the class does not implement
IDisposable (unless I missed something). My strong recommendation would
be to follow the Dispose pattern in all cases involving native resources
so that language / platform facilities (as demonstrated above) can be
taken advantage of.

     References:
     http://msdn.microsoft.com/library/default.asp?url=
     /library/en-us/cpgenref/html/cpconfinalizedispose.asp

Does a reference implementation of the draft (or at least class and
interface definitions in source code form) already exist? Please let me
know so that I can decide how to proceed in respect to integrating
Kerberos. If it doesn't, I would be forced to roll out my own
implementation.

I'd be more than happy to provide you with further input for the sake of
maximizing the value for developers interacting with the GSS-API using
C#.

Thanks for your time, I highly appreciate your work!

Cheers,

Horst.

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten