Some more questions about permissions, apps, and deployment

[David Jencks <da...@yahoo.com>]

I'm still working on understanding the jetspeed security model and  
how the same level of functionality might be exposed from the  
geronimo (or other) JACC system.  I have a few questions that  
although probably rather dumb might help me understand where to head.

1. Is the intended functionality that the "portal" gets deployed with  
no portlet apps available, and then at arbitrary later times any  
number of portlet apps get deployed and registered with  the portal,  
or is the idea that all the portlet apps start at the same time as  
the portal, before any user requests  appear?

2. IIUC a "page" is, well, a psml file describing a page layout, and  
these occur in "folders" which are in fact directories in the portal  
app.  Are these all specified before deployment of the portal or can  
they be modified/created/removed while the portal is running?  If  
they can be modified, does the modification need to occur in the same  
"transaction" as changes in permissions?  In other words, does there  
need to be a way so that a user request sees either the old state  
with the old permissions or the new state with all new permissions?

3. It seems to me that the permissions divide into two types: page/ 
folder/fragment permissions that go with the portal, and portlet  
permissions that go with  the portlet app.  From this point of view,  
the role >> page permission or principal >> page permissions maps  
would be (initially) specified upon deployment of the portal, whereas  
the role >> portlet permission or principal >> portlet permission  
maps would be specified (initially) upon deployment of the portlet  
app.  Is there anything wrong with this point of view?

Thanks
david jencks


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

Re: Some more questions about permissions, apps, and deployment

[David Sean Taylor <da...@bluesunrise.com>]

David Jencks wrote:
> I'm still working on understanding the jetspeed security model and  how 
> the same level of functionality might be exposed from the  geronimo (or 
> other) JACC system.  I have a few questions that  although probably 
> rather dumb might help me understand where to head.
> 
> 1. Is the intended functionality that the "portal" gets deployed with  
> no portlet apps available, and then at arbitrary later times any  number 
> of portlet apps get deployed and registered with  the portal,  or is the 
> idea that all the portlet apps start at the same time as  the portal, 
> before any user requests  appear?
> 
The intended functionality is to support many configurations, such as a 
portal with no portlets available, and portlet apps that get deployed at 
a later time. With the default 'demo' version of Jetspeed, we deploy 6 
demo portlet apps, 1 admin portlet app, and the main portal app 
(jetspeed).  (There is an additional layout portlet application that 
runs as a "local" portlet application, inside of the jetspeed webapp.)

As you can imagine, having 8 web applications inside Tomcat requires 
quite a long startup time during the first initial startup of Tomcat. 
Subsequent startups are much faster.

The aggregation of a page is based off the PSML file which has the 
instructions of how to render a page. Each PSML file contains "portlet 
instances" or references to portlets. In order for a portlet instance to 
render, the portlet has to be already deployed and registered with the 
portal. Thus our demo system, having portlets from several portlet apps 
all on the welcome page, requires quite a few apps to be deployed before 
even starting up. Im working on an alternative demo app, a lighter 
version, that would require only the jetspeed webapp and one or two 
internal portlet apps at startup.


> 2. IIUC a "page" is, well, a psml file describing a page layout, and  
> these occur in "folders" which are in fact directories in the portal  
> app.  Are these all specified before deployment of the portal or can  
> they be modified/created/removed while the portal is running?  

They are defined before hand, however pages and folders can be deployed 
at runtime and modfied/created/removed to the portal site at runtime.

The portal site is a addressable space of file-system-like view of 
folders, pages and links. For example to address the page named "x.psml" 
in the folder "folder-1", it is addressed as "/folder-1/x.psml"

To add a PSML page to the system, simply copy it in and jetspeed will 
pick it up.
(Note: there are two implementation of the PSML(Page) Manager, a 
file-system based impl and a RDBMS impl)

We would also like to support deploying PSML pages inside a webapp (as 
we discussed with Dain at ApacheCon for Geronimo). Along with the 
web.xml and portlet.xml, Jetspeed also supports a jetspeed-portlet.xml. 
One solution would be to specify the pages that are deployed to the 
portal in the jetspeed-portlet.xml...


> If  they 
> can be modified, does the modification need to occur in the same  
> "transaction" as changes in permissions?  In other words, does there  
> need to be a way so that a user request sees either the old state  with 
> the old permissions or the new state with all new permissions?
> 

Perhaps. If the changes are made to security constraints in the page, 
then they are naturally part of the transaction of storing the page:

   <security-constraints>
     <security-constraints-ref>public-view</security-constraints-ref>
   </security-constraints>
</page>

If the constraints-ref were to be modified on a page above, this change 
would occur during the update of the page.

With the permission approach, the change would be made to the 
centralized security policy. The policy would be updated immediately and 
picked up unless some cached policy information was not properly refreshed.

> 3. It seems to me that the permissions divide into two types: page/ 
> folder/fragment permissions that go with the portal, and portlet  
> permissions that go with  the portlet app.  

Yes, two types, but neither are deployed with the portlet app, i.e. both 
are defined in the portal:

1. Security Constraints - built into the PSML (Page) Manager
     constrains access to portal resources:
	- pages
	- folders
	- links
	- portlet fragments

Fragments can be either a portlet instance or a collection of portlets 
on a page. Portlet instances are associated with a page, whereas 
portlets are not.

2. Security Permissions - defined in a JAAS Security Policy
      Java permissions for portal resources:
	- portlets (not portlet instances)
	- pages
	- folders
	- fragment

There are several important differences between a constraints-based 
approach and a permission-based approach. Relevant to this discussion, 
the most important one is that security constraints in jetspeed are 
stored in the page, where as permissions follow the "centralized" policy 
approach, not scattered security policy information interspersed with 
layout in the page or folders. From our experience, we have found needs 
for both cases.


> From this point of view,  
> the role >> page permission or principal >> page permissions maps  would 
> be (initially) specified upon deployment of the portal, whereas  the 
> role >> portlet permission or principal >> portlet permission  maps 
> would be specified (initially) upon deployment of the portlet  app.  Is 
> there anything wrong with this point of view?
> 
> Thanks
> david jencks
> 
Well no unfortunately there is no way to define a "role >> portlet 
permission" or "principal >> portlet permission" mapping in the 
deployment descriptor of a portlet application although the 
<security-constraint> element in the portlet.xml does seem to lead one 
to believe you could. Right now, all security constraints and 
permissions are defined in the portal: either with page security 
constraints or policy permissions.



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