Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 56568 invoked from network); 20 Jun 2005 02:52:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Jun 2005 02:52:40 -0000 Received: (qmail 49042 invoked by uid 500); 20 Jun 2005 02:52:39 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 48963 invoked by uid 500); 20 Jun 2005 02:52:39 -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 48950 invoked by uid 99); 20 Jun 2005 02:52:38 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Jun 2005 19:52:31 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [216.185.189.150] (HELO beluga.contentconnections.com) (216.185.189.150) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Jun 2005 19:52:22 -0700 Received: from localhost (localhost [127.0.0.1]) by beluga.contentconnections.com (Postfix) with ESMTP id 89B2013EC7 for ; Sun, 19 Jun 2005 19:52:25 -0700 (MST) Received: from beluga.contentconnections.com ([127.0.0.1]) by localhost (beluga [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21127-10 for ; Sun, 19 Jun 2005 19:52:22 -0700 (MST) Received: from [192.168.1.108] (ip-66-218-235-51.cableaz.com [66.218.235.51]) by beluga.contentconnections.com (Postfix) with ESMTP id 381E81385A for ; Sun, 19 Jun 2005 19:52:21 -0700 (MST) Message-ID: <42B62F68.6010206@thewallacepack.net> Date: Sun, 19 Jun 2005 19:52:24 -0700 From: Richard Wallace User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [authx] Help with complicated authorization References: <42B310E8.1020308@thewallacepack.net> <1119115870.21857.92.camel@agilis.homelinux.com> <42B46247.3060309@thewallacepack.net> <1119121827.21857.112.camel@agilis.homelinux.com> In-Reply-To: <1119121827.21857.112.camel@agilis.homelinux.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at contentconnections.com X-Old-Spam-Check-By: apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Vincent Tence wrote: > > > > >>I looked into Tapestry a while ago and it seemed overly complicated from >>the very outset. I mean, it seemed to require a lot of work to get even >>a simple webapp up and running. >> >> > >It requires some time to learn it, but once you get it, putting up a >webapp is >pretty easy and fast. The catalog of web components is really cool. > > > >>I'll do some more looking into Tapestry >>because there are some things about JSF I don't like. For one thing, it >>seems like it will be impossible to add form elements in a dynamic >>fashion with DHTML and not doing form resubmits. >> >> > >That's the real plus of Tapestry. It goesa along very well with >traditional HTML development. > > > > > >>It all sounds very cool. Unfortunately, I need to start cranking some >>stuff out right away, so I think I'll need to go with Acegi for now. >> >> > >I can't blame you for that ;-) That's the wise choice for now > > > >> As for where to start, it's hard to say since I'm not familiar enough with >>what's there. I would say probably getting the policy stuff to be more >>dynamic (if it isn't already) would be the first thing to work on. >> >> >> > >Scripted rules are already dynamics. they get reloaded every time the >script file change. XML rules doesn't support that, altough it could be >done. > >I'm curious. How do you make Acegi permissions dynamic? I've not find a >way to fdo that without reloading the Spring Context. > > > I pretty much plan to use the ACL system for assigning users permissions to domain objects. Then the objects a user has permission to and what operations they can perform can change at runtime. It's still a PITA for two reasons: 1) managing the ACLs and 2) possible overhead with checking the ACLs. The first is really a matter of being able to have it be seemless from the users perspective. Users will still have roles and those roles will have mappings to what permissions they should get to an object when they are assigned to it. Changing what permissions a role has or adding new roles would be cumbersome tho. The second is something I'm not entirely sure about with Acegi, but have had to deal with before in an ACL model like this. Basically, when you want a user to be able to do a search on, for instance, all projects assigned to them or to someone else. Of course, you only want to show them what they have access to. Further, links in the HTML table will appear or not appear depending on the types of operations the user can perform on the object and any objects that may compose it. So there is a potential for having several permissions checks when deciding to display a row in the list. I know Acegi can cache permissions checks, but if there are 10000 objects there's no way to be able to cache it all so there is likely going to be a significant performance hit. The way I tried to mitigate that before was to basically say, if a user has role X then they have permissions Y on objects of type Z. But because of the relationships between some of the objects it required writing some special case handling. To be honest, at this point I'm not really sure how I'm going to handle permissions in this system. Every way I try to approach the problem I wind up with a bad taste in my mouth because of inflexibility, performance and/or maintaince problems down the line. Guess that's why I get the big bucks =P (if only heh) Rich