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: neutral (nike.apache.org: local policy)
Message-Id: <88E5FD73-D3E3-4502-B133-B6F2DA4D7649@onehippo.com>
From: David Sean Taylor <d.taylor@onehippo.com>
To: "Jetspeed Developers List" <jetspeed-dev@portals.apache.org>
In-Reply-To: <4A9D35C0.4090206@douma.nu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Permissions
Date: Tue, 1 Sep 2009 13:59:26 -0700
References: <6A98F18E-0772-4DCF-86C2-8589497E8911@onehippo.com>
 <4A9D35C0.4090206@douma.nu>


On Sep 1, 2009, at 7:54 AM, Ate Douma wrote:

> David Sean Taylor wrote:
>> Would anyone object to me moving the Permission classes  
>> (FolderPermission, PortletPermission, BaseJetspeedPermission  
>> etc...)  back into /jetspeed-commons ? I cannot find a way to  
>> easily extend the permission system, something I could easily do in  
>> 2.1.3.
>> For example, from a portlet I would like to do a permission check  
>> from a portlet:
>>        try
>>        {
>>            // use standard Java security to do a permission check  
>> using the seed configuration
>>            AccessController.checkPermission(new  
>> ContactPermission(contact.getID(), "view"));
>>        }
>>        catch (Throwable t)
>>        {
>>            isContactViewable = false;
>>        }
>> But I have to derive my ContactPermission from  
>> BaseJetspeedPermission, living in the security jar
>> I am stuck right now with a 2.1.3 portal using AccountPermissions  
>> that won't port to 2.2, as well as the Contact example above in  
>> another new portal.
>
> Hi David,
>
> The Permission classes, just as our Security Principal classes, were  
> drastically refactored to get rid of the many "wrapped" layers in  
> the 2.1.x security model.
> Permissions are a peculiar beast as they need to extend both the  
> java.security.Permission abstract class as well as be mapped on(or  
> preferably extend) persistent capable classes to be able to store  
> them in the database.
> Without falling back into the old 2.1.x "trap" of creating another  
> wrapping or marshaling/unmarshaling solution this was difficult to  
> implement other than switching to a single public interface  
> (JetspeedPermission) and having to define specific/extended  
> Permission classes within the security component (spi) package.
> Creating a new Permission instance now is delegated to, and thereby  
> controlled by, the new PermissionManager factory methods  
> like .newPermission(String type. String name, String actions).
> Creating/instantiating new Permission types like ContactPermission  
> in the new solution indeed will require adding a new  
> ContactPermissionImpl extending BaseJetspeedPermission in the portal  
> context (e.g. same classpath as the security-component itself).
> You can of course optionally have it implement an interface like a  
> ContactPermission if needed.
> When setup like this, the following could then be an example rewrite  
> of your example above:
>
>   
> AccessController 
> .checkPermission(permissionManager.newPermission("contact",  
> contact.getID().toString, "view"));
>
> I know all this requires a little bit more work then before but  
> AFAIK not *much* more.

This is perfect. My bad, I overlooked the newPermission interface in  
the base factory class. (be nice if the interfaces had javadocs, im as  
guilty of this interface as anyone...)


> Only major difference is the need to provide these Permission  
> classes within the portal classpath, not the shared classpath.
> I suppose(d) the usage of these would be in the portal (security)  
> context anyway, but maybe I'm wrong there.
>
> If you see major problems for converting your 2.1.3 configuration  
> over to the new model I'd like to help out and see if I can come up  
> with a solution. If it really turns out to be problematic, of course  
> we'll have to find a different solution. And, if necessary, even  
> move these base classes back into jetspeed-commons.
> But then we'll have to go back again to a wrapping and marshalling/ 
> unmarshalling solution for persistence as well.
>
>> Additionally, I can only add permission/actions in my seed data  
>> that are validated by JetspeedAction's valid window states or  
>> portlet modes.
> I will have to look deeper into this. Could be we still have some  
> loose ends there.
>
>> Furthermore, for modes like "config" the actions *still* seem to be  
>> failing when loaded from permission-seed-data.
> OK, can you provide me more details?
> I'd like to help out and see if we can solve this.

Simply working from the trunk, edit j2-seed.xml and and then do a  
target=demo build and you will see the error. For example:

		<Permission type="portal" resource="rss::*" actions="view, edit,  
someAction">

or even an extended mode:

		<Permission type="portal" resource="rss::*" actions="view, edit,  
config">

The build will error out complaining about an undefined action. I've  
created a JIRA issue, doesn't matter who works on it, I can get to it  
too

>
>> I would like to propose:
>> 1. moving BaseJetspeedPermission and its derived classes to commons
> Please see above.
> I'm not against it, but I'd like to review first if the current  
> solution cannot be used after all, possibly with some improvements.

No. Your solution works for me. People who are providing their own  
permission classes will have to either drop them in the common class  
loader or in Jetspeed's class loader

>
>> 2. being more lenient on actions (allow any valid string allowed by  
>> Java Permissions)
> +1, but we'll have to investigate how to do this.
> AFAIK in Jetspeed 2.1.3 was as restrictive in this respect or I  
> overlooked something big-time when I devised and implemented the new  
> solution.
>

It probably didn't work as expected in 2.1.3 either, not trying to say  
the new implementation broke something here, just saying "it ain't  
working so lets fix it" :)
JIRA issue:

https://issues.apache.org/jira/browse/JS2-1059


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