You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by David Jencks <da...@yahoo.com> on 2007/08/20 22:22:14 UTC
Re: [Triplesec] Thinking of a quick rewrite -- trigger questions.
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 <ak...@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
>>
>
Re: [Triplesec] Thinking of a quick rewrite -- trigger questions.
Posted by Ersin Er <er...@gmail.com>.
On 8/20/07, David Jencks <da...@yahoo.com> wrote:
>
>
> 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.
I agree. In fact Triggers are designed for replacing client side integrity
handling code. Such deep needs are better to be implemented via
Interceptors.
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.
The current design of the code is not at the state as it's intended to be.
The model changed in time but the implementation may have been introduced
some workarounds to meet those changes. But what I really care is the model,
the implementation can be improved, I know the problems.
So I think I'll leave the interceptor >> trigger change until it
> becomes clearer how to solve these issues.
Well, we can define a way to provide any server side component to SPs.
However I am not sure how good this idea is. Any comments are welcome.
thanks
Thanks David, for dealing with these details.
> 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 <ak...@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
> >>
> >
>
>
--
Ersin Er
R.A. and Ph.D Student at the Dept. of Computer Eng. in Hacettepe University
http://www.cs.hacettepe.edu.tr
Committer and PMC Member of The Apache Directory Project
http://directory.apache.org