Re: Unusual behavior on continuum/redback

[Louis Smith <dr...@gmail.com>]

Just wanted to close this out.  The redback patch was applied to both
Archiva and Continuum, and works perfectly against Oracle LDAP.

Thanks!

Louis

On Thu, Dec 9, 2010 at 8:35 AM, Brent Atkinson <ba...@usm.maine.edu>wrote:

> Louis,
>
> It may not be that their OID setup "isn't secure". It's feasible to have a
> passwordless bind setup, it just means that administrators have to be extra
> careful to setup the schema and ACLs so that sensitive operations and
> information isn't available until users bind with valid credentials. I work
> in an environment with exactly this setup. Using such an LDAP setup you have
> to to verify that 3rd party LDAP authz/authn code doesn't assume binding
> requires a password. Your clients will want to know about this considering
> it may mean they are exposing other services this way as well.
>
> In any case, try the patch out and let us know how it goes. I've applied it
> to our local setup here and it is working great so far. Also, remember to
> drop the patched redback-authentication-ldap jar in *both* continuum and
> archiva's WEB-INF/lib if you're not building both entirely from source.
>
> Brent
>
> >>> Louis Smith  12/08/10 6:32 PM >>>
> I don't think the client wants to hear that their Oracle LDAP isn't secure
> ...and I don't think they know how to configure it to behave the same as
> OpenLDAP ... so they will love hearing that you have a patch to redback
> that
> will "fix the issue" with Archiva and Continuum.  Thank you all!!!
>
> So when can I get the patch, so I can rebuild redback, then build both
> archiva and continuum... and try re-deploying everything?
>
>
> On Wed, Dec 8, 2010 at 6:08 PM, Brent Atkinson wrote:
>
> > Louis,
> >
> > As a follow up, someone has already logged this issue in JIRA as
> > REDBACK-248. I just submitted a patch that addresses allows you to
> configure
> > (defaults should work for your case) whether to allow empty passwords.
> >
> > Brent
> >
> > >>> "Brent Atkinson"  12/08/10 5:31 PM >>>
> > Louis,
> >
> > I suspect things are working exactly as intended. However, let me ask a
> > question and provide an explanation of what I think is occurring.
> >
> > Does authentication fail/succeed correctly when a non-blank password is
> > supplied? If so, I don't think this problem is with continuum (actually
> > redback - the utilized security framework). I think you have the two LDAP
> > servers configured differently. I suspect that you have the OID instance
> > configured to allow password-less binds. The reason the OpenLDAP works as
> > intended is that it is not allowing password-less binds.
> >
> > To test this out, you can use a tool like the Apache Directory Studio
> > plugin in Eclipse. Setup a connection that doesn't supply a password and
> try
> > to connect. If you can enter a blank password and it connects and you can
> > still see a directory tree, then you found the problem. You are using the
> > redback bind authenticator with an LDAP tree that allows people to bind
> with
> > a blank password. I trust you can see the flaw in that approach.
> >
> > To verify that the behavior is possible, I stepped through an
> > authentication attempt against a server that has password-less bind
> enabled.
> > Where things go awry is when redback delegates to the ldap connection
> > factory to connect as a user. The username and password (which is blank)
> are
> > passed along just as they should be. The key event is that the connection
> > actually succeeds. The bind authenticator expects a connect failure to
> > indicate a bad authentication attempt.
> >
> > To handle such ldap configurations to use bind authentication, redback
> > could provide an option to unilaterally treat blank passwords as
> > authentication failures. This could live in the bind authenticator itself
> or
> > be just a normal security option.
> >
> > Hope that helps,
> >
> > Brent
> >
> > >>> Louis Smith  12/07/10 12:00 PM >>>
> > I have verified that this behavior occurs when connecting a working
> > geronimo/continuum to an Oracle OID LDAP.
> >
> > Connecting to an instance of OpenLDAP works correctly.
> >
> > Is anyone out there using Oracle LDAP with Continuum/redback and/or
> > Archiva/redback????
> >
> > Thanks,
> >
> > Louis
> >
> > On Tue, Dec 7, 2010 at 8:08 AM, Louis Smith wrote:
> >
> > > Sorry, wasn't awake yet.
> > >
> > >
> > > Client environment reporting issue:
> > >
> > > Continuum 1.3.6 under Geronimo 2.2 on redhat
> > >
> > > Oracle OID 11.1.1.3 for LDAP,
> > >
> > > My local install (win/geronimo/continuum 1.4.1-SNAPSHOT) against
> OpenLDAP
> > > does NOT show this behavior.  Can't use anything other than a GA
> release
> > at
> > > the client site as it is their production development environment.
> > >
> > > I am going to do a test after hours this evening to use my OpenLDAP
> with
> > > the client's 1.3.6 install and see if it is localized to their Oracle
> OID
> > > configuration.
> > >
> > >
> > >
> > > On Tue, Dec 7, 2010 at 7:47 AM, Wendy Smoak  wrote:
> > >
> > >> On Tue, Dec 7, 2010 at 5:33 AM, Louis Smith
> > >> wrote:
> > >>
> > >> > However, if you enter a valid ID, and leave the password field blank
> -
> > >> you
> > >> > are logged on as that user with all their rights and access.
> > >>
> > >> What version of Continuum (and Redback) are you using?  My 1.3.6-based
> > >> instances don't behave this way.
> > >>
> > >> The configuration is in conf/security.properties.  Perhaps some
> > >> combination of the configurable options has allowed this.
> > >>
> > >> --
> > >> Wendy
> > >>
> > >
> > >
> > >
> > > --
> > > Dr. Louis Smith, ThD
> > > Chief Technology Officer, Kyra InfoTech
> > > Colonel, Commemorative Air Force
> > >
> >
> >
> >
> > --
> > Dr. Louis Smith, ThD
> > Chief Technology Officer, Kyra InfoTech
> > Colonel, Commemorative Air Force
> >
> >
> >
>
>
> --
> Dr. Louis Smith, ThD
> Chief Technology Officer, Kyra InfoTech
> Colonel, Commemorative Air Force
>
>


-- 
Dr. Louis Smith, ThD
Chief Technology Officer, Kyra InfoTech
Colonel, Commemorative Air Force
                                                   <#>
<#>
<#>       <#>