directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <enriqu...@gmail.com>
Subject [SASL] Configuration working.
Date Sat, 17 Mar 2007 09:20:15 GMT
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.  One of my favorite sayings is "The opposite of
incremental is excremental."

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.

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.

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.

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

Enrique

Mime
View raw message