Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 30268 invoked from network); 9 Aug 2007 23:50:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Aug 2007 23:50:58 -0000 Received: (qmail 55395 invoked by uid 500); 9 Aug 2007 23:50:49 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 55363 invoked by uid 500); 9 Aug 2007 23:50:49 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 55345 invoked by uid 99); 9 Aug 2007 23:50:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Aug 2007 16:50:49 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 64.233.166.178 as permitted sender) Received: from [64.233.166.178] (HELO py-out-1112.google.com) (64.233.166.178) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Aug 2007 23:50:44 +0000 Received: by py-out-1112.google.com with SMTP id d32so1321545pye for ; Thu, 09 Aug 2007 16:50:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=faVXf2BBntir1diB5ew17p416BTr0PFhehY4sNEc8nRUVUWW4aqVzQ2cPq4qKK07nFjZDPwzNHSinjXkvUFaTsU4JyC52HiphC35wDzcwpEsHm1jE5t2ZiceU0jDEHU5MZpkNHb2L3ECDfBOamS/HcXQ9H/OW6jL6SaC4QPzA+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=tpnXM0ixNkJxiTX17fUWPT5pWWdMb9JM6T3MDLawYd7k77aDC/lIc6KDT4cr9y5H/2vZPEtyB5jRNJRJWS8CvjEH87RGYTeU4DGWnrk3M6sgUpE9f4ZsdsoTOyNZDy/YPJ5gUUm5hDAZ7KPUX9pqC54xj+VzBblxLEUuLilSGSU= Received: by 10.142.158.17 with SMTP id g17mr498944wfe.1186703421975; Thu, 09 Aug 2007 16:50:21 -0700 (PDT) Received: by 10.142.101.21 with HTTP; Thu, 9 Aug 2007 16:50:21 -0700 (PDT) Message-ID: Date: Thu, 9 Aug 2007 19:50:21 -0400 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" Subject: Re: [Triplesec] Thinking of a quick rewrite In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17753_27841525.1186703421925" References: X-Google-Sender-Auth: 16da65377203f404 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_17753_27841525.1186703421925 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi David, On 8/9/07, 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? 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. - 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. - 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. 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. Regards, Alex ------=_Part_17753_27841525.1186703421925 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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.

- 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.

- 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.

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.

Regards,
Alex


------=_Part_17753_27841525.1186703421925--