directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [SASL] Configuration working.
Date Sat, 17 Mar 2007 13:13:55 GMT
Enrique,

On 3/17/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
>
> Hi, Directory developers,
>
> I have SASL updated and working great with the results of our
> discussions from this week.  I have to say, I'm pretty psyched to have
> this running with a lot tighter configuration, even if it is more of
> the same Spring XML.


That's wonderful.  I'm excited to have SASL with a tighter configuration
than using env properties.

One of my favorite sayings is "The opposite of
> incremental is excremental."


Heh I like that too.

I noticed one easy improvement to configuration that I've seen in
> other servers using SSL, such as Tomcat and Jetty.  In Jetty, for
> example, you have a "Server" with "Listeners," each Listener on its
> own port, paraphrased here:
>
> <Server>
>   ...
>   <Listener>
>     <Port="80">
>   </Listener>
>   ...
>   <Listener>
>     <Port="443">
>   </Listener>
>   ...
> </Server>
>
> IMO it makes a lot of sense to have separate beans for LDAP and LDAPS.
> The underlying class, LdapConfiguration, would be identical but we'd
> have 2 beans instead of today's ldapPort and ldapsPort in one bean.


Yeah this sounds pretty sane to me.

With the other 4 protocols, I have a base class called
> ServiceConfiguration specifically meant for the parameters common to
> all protocol's, such as ipPort, ipAddress, JNDI authentication, etc.
> If we went with separate beans for LDAP and LDAPS I could have
> LdapConfiguration extend ServiceConfiguration and all the protocols
> would be very similarly configured.  For example, every protocol would
> have the common parameters ipPort and ipAddress (to bind to in
> multi-homed scenarios).  One of the really cool things this sets us up
> for is having an LDAP schema for the aforementioned common parameters.
> In fact, this is how we do dynamic re-configuration with Config Admin
> in the OSGi build.


OK you've got my attention here even though this is more scope creep into
your SASL branch.  However it does not sound like all that much to get done.

BTW it looks like you're close to finishing this off so we might just push
this
into 1.5.0.  Also I will make sure I fax in that StartTLS grant today:
finding my
fax machine is #1 on my agenda after hitting send here.

More to the immediate needs of SASL, in lieu of more advanced config
> someday, this would make it easier to handle what I think is a common
> usecase, namely that authentication requirements are different for
> LDAP vs. LDAPS.  For example, admins could configure an LDAPS bean to
> allow anonymous and/or simple auth connections while the LDAP bean
> could require stronger authentication.  Separate beans would allow
> separate SASL configuration with very little work.
>
> So, to summarize we would have:
>
> <bean class="MutableServerStartupConfiguration">
>   <bean id="ldapConfig" class="LdapConfiguration">
>     <property name="ipPort" value="389"/>
>     ... SSL config for Start TLS ...
>     ... SASL config ...
>   </bean>
>   <bean id="ldapsConfig" class="LdapConfiguration">
>     <property name="ipPort" value="689"/>
>     ... SSL config for LDAPS ...
>     ... SASL config ...
>   </bean>
> </bean>
>
> Having a protocol with 2 ports is a throwing wrench into my protocol
> configuration class hierarchy.


Understood.  I can see this problem clearly now.

I could finish this and be stable with SASL this weekend.


Let's go for it.  I agree with all your points in this email.

Alex


Enrique
>

Mime
View raw message