continuum-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Louis Smith <dr.louis.sm...@gmail.com>
Subject Re: Unusual behavior on continuum/redback
Date Fri, 07 Jan 2011 12:36:48 GMT
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 <batkinson@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
                                                   <#>
<#>
<#>       <#>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message