directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [Triplesec] Thinking of a quick rewrite
Date Fri, 10 Aug 2007 20:56:30 GMT
Hi David,

On 8/9/07, David Jencks <david_jencks@yahoo.com> wrote:
>
>
> On Aug 9, 2007, at 4:50 PM, Alex Karasulu wrote:
>
> Hi David,
>
> On 8/9/07, David Jencks <david_jencks@yahoo.com> 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?
>
>
> No I intend to work on it but I realized that other things also need to be
> done
> to make this rewrite successful so I began working on those matters.  Now
> I am a bit off line but will get back into the groove shortly.
>
> I'm going to resume working on my sandbox triplesec-jacc.  I'm going
> > to start by:
>
>
> Well we discussed several issues with the schema and the way we use
> groups.  There is more discussion required on this topic but feel free to
> keep working on it since I have gained some insite on several things by
> looking into this branch.  However also note that we have done some
> pkg refactoring in the triplesec trunk already which also is not part of
> any rewrite.
>
>
> I'm not so against groups as I was the last time we talked :-)
>
>
> - change package to o.a.d.triplesec
> > - change the OIDs to ones appropriate for apache.
>
>
> Yeah I think we did this or need to definately.
>
> - use maven-remote-resources-plugin for LICENSE/NOTICE files
>
>
> Ohhhh more to learn from your branch :).
>
> - remove admin ui with the intention of using ldap studio instead
>
>
> Ahh yes we must do this eventually yes yes.
>
> - use triggers instead of the interceptors (if I can figure out how
> > and there is enough support for them in trunk)
>
>
> Aye this will clean up much craptastic code.
>
> - figure out how to use xbean-spring to configure the server
>
>
> Ooohh this is where we differe I will start removign Spring and
> start pushing the configuration into the DIT.  THis will reduce
> more code in Tsec.
>
>
> well... good luck :-)  but this isn't a good place to discuss this issue.
>
>
> - model more of the NIST RBAC model (see http://csrc.nist.gov/rbac/
> > rbacSTD-ACM.pdf)
>
>
> Yes this is where I need to do some research as well.  But I have some
> nice ideas here with how to deal with permission extension without
> compromising
> specificity for a specific language or platform.
>
> 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.
>
>
> Aye agreed.
>
> 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.
>
>
> I definitely think we can merge our efforts but we need better
> collaboration.  I
> blame myself for slipping here so please forgive me on this.  Also the
> communication
> has been somewhat poor.  I think we can balance the jacc vision without
> compromising
> generalized usage.
>
> 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.
>
>
> Take a look here:
>
>    http://cwiki.apache.org/DIRxPMGT/oid-assignment-scheme.html
>
> HTH.
>
>
> That's quite useful but not quite definitive :-).  I guess the first thing
> is to check if triplesec trunk has update the oids...looks like "no".
>

I don't think it has so yes you are right.  It is using a Safehaus based OID
branch.

So should triplesec (lets assume we can merge our efforts) get
> 1.3.6.1.4.1.18060.0.4.6
> and then
>  1.3.6.1.4.1.18060.0.4.X.0  ApacheDS LDAP Schema syntaxes
> 1.3.6.1.4.1.18060.0.4.X.1 ApacheDS LDAP Schema matchingRules
> 1.3.6.1.4.1.18060.0.4.X.2 ApacheDS LDAP Schema attributeTypes
> 1.3.6.1.4.1.18060.0.4.X.3 ApacheDS LDAP Schema objectClasses
> 1.3.6.1.4.1.18060.0.4.X.4 ApacheDS LDAP Schema dITStructureRules
> 1.3.6.1.4.1.18060.0.4.X.5 ApacheDS LDAP Schema nameForms
>
> where X == 6 for the different types?
>

1.3.6.1.4.1.18060.0.4.6 is the branch you are creating for Triplesec?  If
you take another
look at the document we already allocated 1.3.6.1.4.1.18060.0.1 as the Tsec
base.  You
can then assign various kinds of schema elements to OIDs off this base.
Here's what I
would do:

1.3.6.1.4.1.18060.0.1.0  Tsec LDAP Schema syntaxes
1.3.6.1.4.1.18060.0.1.1 Tsec LDAP Schema matchingRules
1.3.6.1.4.1.18060.0.1.2  Tsec LDAP Schema attributeTypes
1.3.6.1.4.1.18060.0.1.3  Tsec LDAP Schema objectClasses
1.3.6.1.4.1.18060.0.1.4  Tsec LDAP Schema dITStructureRules
1.3.6.1.4.1.18060.0.1.5  Tsec LDAP Schema nameForms

> I'd like to talk to you more about this and see if we can align better but
> I don't
> blame you for forging ahead due to my lack of participation.  Let's just
> keep
> working forward as you are stating and try to keep collaborating and
> learning
> from one another.  I'm sure we can find some things of value during this
> process
> even if we cannot merge the code bases.  I think it would be premature to
> split
> our effort and short the potential to align at some point.
>
>
> Excellent!  I would much prefer to work together on this but pretty much
> have the impression you don't want me mucking around in triplesec trunk.
>

Well I don't think we've reached a full agreement yet but we're not far
off.  Neither
of us have enough of an understanding or enough time collaborating to
understand
how to model the policy store correctly.  I think I have some good ideas but
have
not had time to validate them.  I would like to share them with you before
we start
ripping up the code with experiments in the trunk.  This is why the branches
where
we experiment with ideas are cool for me.

If I'm wrong... let me know.  I certainly headed down some dead ends on my
> first attempts and given my general ignorance of ldap I can't do this all by
> myself.
>

Yes I think I would love to work with you on the trunk but we need to know
where
we're going to go.  BTW I do think that I can impart a few LDAP things to
you on
these matters to make life easier for both of us and to reach that common
vision.

I think after the stuff I've proposed what is left will be a lot easier to
> see and we can have an easier time discussing the schema which is really the
> core to it all.
>

Absolutely I agree 100% with this comment.  Yes let's keep trying to find
common ground.
I wish I could spend a good week just focusing on this with you to nail this
thing down solid.

Regards,
Alex

Mime
View raw message