[jcifs] JCIFS, Kerberos

[John Baker]

Andre,

Use this:  http://spnego.sourceforge.net/

jcifs and NTLM isn't the answer.


John

> On Tue, Dec 1, 2009 at 3:52 AM, André Warnier <aw at ice-sa.com> wrote:
>> Hi.
>>
>> I would not like anyone to spend a long time on this, but could someone
>> briefly outline what are the differences in authentication mechanisms
>> between a Kerberos and non-Kerberos situation, from a jCIFS point of
>> view ?
>> (Or provide some pointers to that effect, other than a pure Kerberos
>> introduction).
>> I have a superficial knowledge of Kerberos in general, and a somewhat
>> better
>> understanding of the NTLM authentication mechanism, but what I do not
>> entirely understand is why there have to be 2 separate versions of JCIFS
>> authentication to handle the Kerberos case.
>
> Hi André,
>
> There are separate branches of JCIFS for NTLM and Kerberos mostly
> because JCIFS uses NtlmPasswordAuthentication objects (NPAs for short)
> throughout the entire codebase. These need to be ripped out in favor
> of the Subject based security model used by JAAS. That touches a lot
> of code and is a major change to the API which equates to something
> that must happen with the indefinitely postponed release of JCIFS 2.0.
> The NTLM and Kerberos protocols are totally different but that does
> not really matter because that is not really the impediment to getting
> JCIFS to do both. Doing Kerberos with JCIFS is actually not that hard.
> The problem is simply the API is not ready for it.
>
> What I would like to see happen is to use the concept of a
> "SecurityProvider" that abstracts the different mechanisms including
> NTLM, Kerberos and SPNEGO (which is just a useless wrapper for NTLM or
> Kerberos) and provides authentication, integrity, confidentiality
> (like GSSAPI but not insane) and access to certain properties like
> session keys, domain names, ntlmssp flags and so on. Because a
> SecurityProvider is basically just a Map of properties with a few
> security specific methos, JCIFS can use any provider and require only
> that it emit and consume the security tokens necessary to perform
> client-side authentication and possibly provide aforementioned
> properties.
>
> Anyway that's the plan. Whether it will happen or not is another story
> entirely.
>
> Mike
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/
>
>