You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Roland Weber <os...@dubioso.net> on 2008/03/08 10:14:24 UTC
plugin point for NTLM integrated Windows authentication
Hi Cathy,
maybe you can put the plugin point for integrated Windows
authentication into the equivalent of the NTCredentials [1].
For the sake of discussion, I will assume that the critical
hash computation requires two kinds of input:
a) some sort of challenge, seed, or init vector which is
computed from the received authentication challenge
b) user credentials, either in the form of domain/name/pwd
or from a native call
So my suggestion is...
/** Compute NT hash in pure Java. */
public class NTHasher {
public static int computeNTHash(challenge,domain,name,pwd) {
...
}
}
/** Obtain a hash for a challenge, generic. */
public interface NTHashProvider {
int computeNTHash(challenge);
}
/** Pure Java credentials. */
public class NTCredentials implements NTHashProvider {
attributes: domain,name,pwd
int computeNTHash(challenge) {
return NTHasher.computeNTHash(challenge,domain,name,pwd);
}
}
/** Windows system credentials. */
public class WinSystemCredentials implements NTHashProvider {
int computeNTHash(challenge) {
...do something native or platform specific...
}
}
With this approach, the system credentials are treated in the
same way as other credentials. There is no "backchannel" where
the authentication framework has to check for a platform specific
mechanism to invoke. If an application wants to use integrated
Windows authentication, it provides the WinSystemCredentials.
An application that doesn't will behave on Windows exactly as
it behaves on other platforms. We also wouldn't need an extra
mechanism to handle authentication failures. If the system
credentials are not what the server or proxy wants, that is just
the same as providing a wrong password in the pure Java credentials.
With only one or two interfaces and maybe a base class that ties
the WinSystemCredentials into HttpAuth, it should also be easy
to reuse the platform specific code in projects that do not rely
on HttpClient for HTTP and NTLM.
cheers,
Roland
[1]
http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/NTCredentials.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: plugin point for NTLM integrated Windows authentication
Posted by Cathy L Kegley <ck...@us.ibm.com>.
Hi Roland,
This is similar to what I had in mind, so it's good to know you are on the
same page. With integrated authentication the user name, password, host
name, and domain name are all obtained automatically from the client.
Correct me if I'm wrong, but currently, the HttpClient requires an instance
of NTCredentials for NTLM authentication, so WinSystemCredentials would
need to be a subclass of that and provide its own implementation to get the
domain, host, and user as well as the needed hashes. Then NTLM.java should
be instantiated with an instance of NTCredentials. This would eliminate
the need for NTLMScheme.java to pass in the username, password, domain, and
host into every method that needs it. NTLM.java will then rely on its
instance of NTCredentials to obtain the information that it needs.
Cathy Kegley
From: Roland Weber <os...@dubioso.net>
To: HttpComponents Project <de...@hc.apache.org>
Date: 03/08/2008 03:12 AM
Subject: plugin point for NTLM integrated Windows authentication
Hi Cathy,
maybe you can put the plugin point for integrated Windows
authentication into the equivalent of the NTCredentials [1].
For the sake of discussion, I will assume that the critical
hash computation requires two kinds of input:
a) some sort of challenge, seed, or init vector which is
computed from the received authentication challenge
b) user credentials, either in the form of domain/name/pwd
or from a native call
So my suggestion is...
/** Compute NT hash in pure Java. */
public class NTHasher {
public static int computeNTHash(challenge,domain,name,pwd) {
...
}
}
/** Obtain a hash for a challenge, generic. */
public interface NTHashProvider {
int computeNTHash(challenge);
}
/** Pure Java credentials. */
public class NTCredentials implements NTHashProvider {
attributes: domain,name,pwd
int computeNTHash(challenge) {
return NTHasher.computeNTHash(challenge,domain,name,pwd);
}
}
/** Windows system credentials. */
public class WinSystemCredentials implements NTHashProvider {
int computeNTHash(challenge) {
...do something native or platform specific...
}
}
With this approach, the system credentials are treated in the
same way as other credentials. There is no "backchannel" where
the authentication framework has to check for a platform specific
mechanism to invoke. If an application wants to use integrated
Windows authentication, it provides the WinSystemCredentials.
An application that doesn't will behave on Windows exactly as
it behaves on other platforms. We also wouldn't need an extra
mechanism to handle authentication failures. If the system
credentials are not what the server or proxy wants, that is just
the same as providing a wrong password in the pure Java credentials.
With only one or two interfaces and maybe a base class that ties
the WinSystemCredentials into HttpAuth, it should also be easy
to reuse the platform specific code in projects that do not rely
on HttpClient for HTTP and NTLM.
cheers,
Roland
[1]
http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/NTCredentials.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org