This is great guys.  I also talked to Stefan Seelmann on IRC and he's also
interested in working on this.  I'm thinking Chris might also be interested
as well and he can chime in when he comes online.  So for now I'll presume
we have the following list of committers:


Let me figure out the pieces we can chew off on this below.  Just thinking out
loud so please chime in.

Configuration in DIT (CiD) Team

   Move configuration parameters within the server.xml file into the DIT using a custom
   configuration schema for ApacheDS and Triplesec.  For this pass the configuration
   need not be dynamic which can be retrofitted later.  We can use smart defaults when
   the server starts so users can configure it then restart the server.  In the process the
   Directory Studio guys on the team can expose these configuration parameters in the
   DIT with custom wizards in Studio however this is not the immediate aim of this effort.

Triplesec Schema Team

   Redesign the Triplesec schema for cleanup and to support multi-realm configurations.
   Use triggers and stored procedures instead of a custom interceptor for maintaining
   referential integrity.  Add extension objectClasses for permissions to enable the
   backing use of various kinds of instances.  Triplesec should
   be able to be used as a JSE policy store and eventually once we conclude on how as
   a JACC provider.  Use new schema subsystem instead of the old 1.0 mechanism.

Triplesec Installers Team

   Migrate installers/boostrappers to support the Tanuki based changes being
   introduced into the 1.5.x branch by Chris.  Handling migration of Jetty into
   ApacheDS core.  Rewrite some existing configuration and web demo
   applications to leverage CiD and utilize the new Kerberos clients that Enrique
   is working on.  Although somewhat unrelated we have to move the Jetty
   integration code from Triplesec into ApacheDS so ApacheDS can leverage
   it and Triplesec becomes lighter.

Triplesec Documentation Team
   Update all documentation to reflect the changes in Triplesec.

I think these teams can start working with some good isolation and we will
pretty much have all main issues in this list knocked out.  Some things like
the better use of Maven and logging are horizontal aspects that we can all
manage as we deal with our individual issues.

I am going to start working in the new triplesec area just moving some basic
packages (libs) and doing the package renaming with a clean maven setup.
We can work out of the following SVN base:

I guess the next step is to look into some plan of attack for all this.  I will
try to formulate something we can discuss in another email a few days

How does this breakdown in labor sound so far?  Comments? Suggestions?


On 7/3/07, Pierre-Arnaud Marcelot <> wrote:
I'm also interested in.

I'll be happy to give you a hand.


On 7/3/07, Alex Karasulu <> wrote:
Hi all,

For the past couple days I've been looking at migrating Triplesec packages and just
cleaning up the project as a whole since it is pretty much a prototype as it stands
right now.  There are a few things in Triplesec that I have problems with:

(0) bring all NOTICE and LICENSE files up to date with review
(1) It package names are not based
(2) It uses ApacheDS 1.0.3 and I would like to start using 1.5.x
(3) It has Jetty integration which I would like to move into ApacheDS and inherit
(4) The schema is a mess and needs to be cleaned up as well as massaged to not use
     safehaus prefixes.
(5) server.xml file handling to reconfigure the server is a mess with dom4j based loading
     and rewriting so DIT based configuration can significantly clean up this mess
(6) junit extensions for integration testing is causing issues on windows and failing
     even on linux due to some maven peculiarities with classloaders
(7) very poor logging
(8) lack of HOTP parameterization per account
(9) I would like to remove the interceptor used for referential integrity and replace it
     with triggers and stored procedures
(10) I want the maven build to work using all the tricks we learned to stop maven
      from changing under our feet with snapshotted plugins
(11) rework the installers to use Chris' work with Tanuki and the various installers

Right now I would like to build flexibility into the schema and the format to support
multiple realms.  Also I would like to consider flexibility to support JACC however
it's not the primary aim for now and can be ignored for this quick rewrite.

After assessing where we are and what we have to do a rewrite may take less effort
than wrestling with all the problems we have.  Also note that some key libraries need
not be completely rewritten.

I have the month of July only to do this if I do set out to do it.  I also need some help
but this rewrite gives a bunch of us (especially the new comers) a chance to get up
to speed with Triplesec. 

So now I have a few questions for the community:

(1) Should we do this rewrite which will take a couple weeks off our schedule but
     may give significant advantages in the future?
(2) Who is interested in tackling this with me?

If we have enough people and agreement then we can just jump in and get started.