directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [Triplesec] Thinking of a quick rewrite
Date Thu, 09 Aug 2007 23:29:27 GMT
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 <akarasulu@apache.org> 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
>


Mime
View raw message