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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
