As far as I can tell from looking at svn basically nothing happened
with this effort and from the original note now july is over so Alex
doesn't have time to work on it any more?
I'm going to resume working on my sandbox triplesec-jacc. I'm going
to start by:
- change package to o.a.d.triplesec
- change the OIDs to ones appropriate for apache.
- use maven-remote-resources-plugin for LICENSE/NOTICE files
- remove admin ui with the intention of using ldap studio instead
- use triggers instead of the interceptors (if I can figure out how
and there is enough support for them in trunk)
- figure out how to use xbean-spring to configure the server
- model more of the NIST RBAC model (see http://csrc.nist.gov/rbac/
rbacSTD-ACM.pdf)
My copy was running against apacheds 1.5 back in january but it
doesn't compile any more due to big changes in interceptor
interfaces. I think that using triggers should make it less
sensitive to such interface changes.
I'd be happy to move this either to the rewrite branch or to geronimo
depending on whether the community thinks this direction is worth
exploring or is definitely of interest only for geronimo.
One question I have is how to assign appropriate oids to the schema
elements. Previously I was just incrementing existing numbers but
this is obviously not quite correct to get the OIDs to be correct for
apache. I'd definitely appreciate some advice on this point.
thanks
david jencks
On Jul 17, 2007, at 6:11 PM, David Jencks wrote:
Is this progressing? I imagine you guys already know this, but my
copy of triplesec used apacheds 1.5-snapshot from around january
and had what I consider a considerably improved persistence
mechanism -- sort of like jdo except you enhance by hand.
I'm hoping to have some time to work on triplesec shortly....
thanks
david jencks
On Jul 9, 2007, at 4:52 AM, Emmanuel Lecharny wrote:
Hi Alex,
I'm +1 for any kind of way for the team to jump into the TSec train.
Having a prototype is a really valuable thing as it demonstrates what
is TSec, but now, if we are to using it more widely, we need to
transform this prototype into a product.
I would say that you should not get invorlved in tasks like 0 and 1,
as we can do that out of band (I already did it for ADS and MINA, it
took me a couple of day, but as I was brain dead, it was perfect)
Task 2 should not be a big issue, and it can helps to do the maven
migration (Task 10).
Task 3 is very important, and must be well documented, as we will use
it for other purposes. May be someone else in the team want to give a
hand ?
Anyway, i'm not 100% sure I will be able to help a lot in the next
few
weeks, so please consider me as a little bit off.
On 7/3/07, Alex Karasulu <[EMAIL PROTECTED]> 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 org.apache.directory.triplesec 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.
Alex
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
