[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster-devel] forcing authentication via ldap?



Brad Clements wrote:
On 6 May 2006 at 22:20, Marcel Ruff wrote:

The client needs to send the specific SecurityQos markup as expected
by the server plugin:

<securityService type="ldap" version="1.0">
   <user>joe</user>
   <passwd>secret</passwd>
</securityService>

what would you want to send instead?

I find this security architecture to be very strange. The very idea that the client, who is not yet authenticated, can tell the server which authentication service to use, seems bizarre. I suppose it's ok if the server can be configured to only support a single authentication type.
So you like to send credentials like this:

<securityService>
  <user>joe</user>
  <passwd>secret</passwd>
</securityService>

The server then automatically chooses the default authentication mode
as you have described below - sounds reasonable - but needs to be implemented in org.xmlBlaster.authentication.plugins.PluginManager.java



However in my test, I commented out every security.server plugin (including htpasswd) and I still was able to authenticate with a fabricated userid and password.
It falls back to htpasswd, please try to set

Security.Server.Plugin.htpasswd.secretfile=${user.home}${file.separator}xmlBlaster.htpasswd

(take a copy from xmlBlaster/config/xmlBlaster.htpasswd)

and try

 java HelloWorld3 -session.name guest -passwd secret
or
 java HelloWorld3 -session.name guest -passwd secretXX
In my use case, I want every client to authenticate via ldap. I will be running xmlBlaster on an "open port", I cannot rely on potential hackers to specify type="ldap" when they connect ;-)

(So, when I get SSL working I'll use certs to help protect xmlBlaster, but until then ...)

You can probably try to force the ldap plugin as a server side default
like this:


Security.Server.Plugin[htpasswd][1.0]=org.xmlBlaster.authentication.pl ugins.ldap.ClientPlugin

but i haven't tried it.


It doesn't work, see below

Hmm, we should change the plugin manager code to allow a nicer way to
change the default plugin...

I think there needs to be an explicit way to say "these are the allowed authentication methods, and here's the order they should be tried if the client didn't specify the type".


Or even, a mapping that says, these IP addresses can use these authentication methods.

Which leads to this problem. I tried tricking htpasswd to by ldap, and during startup it fails.

May 7, 2006 10:47:01 AM  INFO   10-XmlBlaster.MainThread org.xmlBlaster.authentication.plugins.ldap.Session <init>: Initializing LDAP access on ldap.serverUrl='ldap://ldap.strader-ferris.com:389/dc=strader-ferris,dc=com' with rootdn='cn=Manager,dc=strader-ferris,dc=com'. The unique uid field name in ldap should be 'uid'.
May 7, 2006 10:47:01 AM SEVERE  10-XmlBlaster.MainThread org.xmlBlaster.authentication.Authenticate connect: PANIC: Access is denied: org.xmlBlaster.authentication.plugins.htpasswd.SecurityQos
java.lang.ClassCastException: org.xmlBlaster.authentication.plugins.htpasswd.SecurityQos
        at org.xmlBlaster.authentication.plugins.ldap.Session.init(Session.java:72)
        at org.xmlBlaster.authentication.Authenticate.connect(Authenticate.java:300)
        at org.xmlBlaster.authentication.AuthenticateProtector.connect(AuthenticateProtector.java:77)
        at org.xmlBlaster.authentication.AuthenticateProtector.connect(AuthenticateProtector.java:65)
        at org.xmlBlaster.protocol.jdbc.JdbcDriver.activate(JdbcDriver.java:187)
        at org.xmlBlaster.protocol.jdbc.JdbcDriver.init(JdbcDriver.java:113)
        at org.xmlBlaster.util.plugin.PluginManagerBase.instantiatePluginSecondPhase(PluginManagerBase.java:258)
        at org.xmlBlaster.util.plugin.PluginManagerBase.getPluginObject(PluginManagerBase.java:107)
        at org.xmlBlaster.engine.runlevel.RunlevelManager.startupPlugins(RunlevelManager.java:294)
        at org.xmlBlaster.engine.runlevel.RunlevelManager.changeRunlevel(RunlevelManager.java:225)
        at org.xmlBlaster.Main.init(Main.java:181)
        at org.xmlBlaster.Main.<init>(Main.java:117)
        at org.xmlBlaster.Main.main(Main.java:600)



But watching the ldap connection with ethereal, xmlBlaster does bind successfully, and I don't see any other ldap requests. So, it seems like xmlblaster, during startup, is trying to login to itself? .. and it doesn't actually send any requests to the ldap server for that login.
Please see the few classes in xmlBlaster/src/java/org/xmlBlaster/authentication/plugins/ldap
and read the javadoc there.
If your approach is only slightly different you could add a switch for your mode,
else you need to write your own,


best regards
Marcel