Mailing-List: contact jetspeed-dev-help@portals.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@portals.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=hre2Uk4At8vz3FB9v+v1utKv+BLZHOhGb/Ivfj5OucmCwo2t+q760q2zJb0YtYCchM/ogmNrFSQd5GzEsGR6PA6vl0sMItkGs92RZN7sXlntxXG9hmPHL9hekkO2xVmnybiD7mRWdRToZmM6gNk/GpzaBbK7byd/WM9Jr20YhxU=
  ;
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <469D515A.8030101@douma.nu>
References: <469B894B.5040807@douma.nu>
 <E4EBAAEA-83AE-48FF-A84D-371196FDF53B@yahoo.com> <469D515A.8030101@douma.nu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9B3C4609-40B0-4755-A326-1C0B36415413@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: Further Jetspeed-2 development plans  -- security
Date: Tue, 17 Jul 2007 17:28:37 -0700
To: "Jetspeed Developers List" <jetspeed-dev@portals.apache.org>


On Jul 17, 2007, at 4:31 PM, Ate Douma wrote:
>>>

<giant snip>
>>> - review and redesign our portal security model and implementation
>> I'd  very much like to help with this and might even have enough  
>> time :-)
>> The last time I looked (1.5 years ago) I wanted to go for a  
>> security model that worked entirely on Permissions.  IIRC the  
>> objection at that time was that the non-Permission scheme could  
>> deny as well as grant permissions: I think that we can do that  
>> with Permissions as well.
>> There's a apache directory subproject called Triplesec that I'm  
>> also trying to find enough time to work on and I think may have  
>> some useful ideas on how to organize permissions and possibly  
>> other aspects of this.
> Please bring them up, I'm open to discuss this again and properly  
> so now.

This may take a few days to get organized...

> As its been a long time, can you also please describe why you think  
> we can/should base our security model (entirely) on Permissions?
> Our current Constraints based model has served us well, so would we  
> be able to maintain that too (possibly on top of a Permissions  
> based scheme)?

Its been about 18 months :-((((( but IIRC the only functional  
difference between the constraints model and the permissions model  
was the ability to deny permissions in the constraints model.     
There's nothing inherent in mapping users/roles to permissions that  
keeps you from denying permissions to users/roles, it's just that the  
"standard" jacc model doesn't talk about it.  So my idea is very  
roughly that the portal code will construct a suitable permission at  
appropriate places and submit it to the security system for  
checking.  The security system could be jacc in a javaee server, or  
it could be a jetspeed component that matches the behavior of the  
current constraints model.  My hope is that the authorization system  
can be easily pluggable and have only one set of code inside the portal.

I didn't do any profiling or serious investigation but it also looked  
to me as if there was a a lot of redundant security checking going  
on: of course this might have been cleaned up since I looked at it.

>
>>> - multiple authentication/authorization schemas to support truly  
>>> separated access & maintenance of "communities" in one portal
>> I'm not quite sure what you mean here, but it sounds interesting.
> Being able to "deploy" multiple sites in one portal, each with  
> their own set of users and security scheme.
> This will allow to use a single portal instance (although possibly  
> clustered) for different (set of) groups/users/customers, e.g.  
> "communities", each with their own personal/separated "site".
>
Either I forgot something or I don't understand some important bits  
of what's there now.  Why can't we do this now?

thanks
david jencks


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org