On Aug 9, 2007, at 4:29 PM, David Jencks wrote:
> 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)
I looked into this a bit and see two problems I don't know how to
solve and one big worry:
Recall that the triplesec referential integrity code is implemented
in PolicyProtectionInterceptor and ApplicationAciManager. These are
initialized at server startup with the DirectoryServiceConfiguration
which they use for:
- factoryCfg.getRegistries().getAttributeTypeRegistry
().getNormalizerMapping()
IIUC this can be accessing in a trigger
- factoryCfg.getRegistries().getAttributeTypeRegistry().lookup
( "administrativeRole" )
- factoryConfiguration.getEnvironment()
I don't see any way to get these from a trigger/sp.
Also I'm worried about speed issues since it appears from my quick
reading of the code that each stored procedure invocation involves
creating a new classloader and a lot of lookups.
So I think I'll leave the interceptor >> trigger change until it
becomes clearer how to solve these issues.
thanks
david jencks
> - 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
>>
>
|