portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Permissions
Date Tue, 01 Sep 2009 14:54:56 GMT
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,

I know all this requires a little bit more work then before but AFAIK not *much* more.
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.

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

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



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

View raw message