On Tuesday, March 9, 2004, at 12:42 PM, [EMAIL PROTECTED] wrote:
Hello jetspeed 2 team!me too ;)
I'm going to build an enterprise portal based on jetspeed 2 for a large governamental organisation in the Netherlands.
The previous weeks I've also evaluated ExoPortal (can't use because of GPL),
GridSphere (nice but to restricted) and Liferay (also nice but far to bloated
and peculiar).
Except for ExoPortal Jetspeed 2 is certainly the most modular and flexible and,
although far from complete, hopefully ready for (beta) production use before
the summer (otherwise I will be in trouble :-)
The coming weeks/months I probably will bug you a lot but I'm also allowed tolayouts in jetspeed-2 are portlets
contribute features and patches back to you which I certainly will try to do as
much as possible.
I will first give a short summary of the features I have to implement:
- 2 column page layout: - on the left a portlet menu portlet - on the right one portlet without any window decoration (no portlet window modifications or portlet edit allowed)
so you can package them as a portlet application or contribute layouts to the default portlet application
we currently have one layout, a 2 column page
hope to have more real soon
yes, we will need to port many of the J1 administrative portlets to J2 and as Portlet API compliant- base portlets - menu (see above) showing only accessible portlets - custom user maintenance - custom group mainteanance - custom user / group maintenance - custom portlet role maintenance - custom portlet role / group maintenance - custom portlet access maintanance (using custom group & role) - login - change password
The security model is changing also
After I have this initial portal working several applications will be ported to
the web as JSR-168 portlets. It is expected that some 1500 users will use the
portal on daily basis.
For the (application) portlets I also have to define development standards
(environment, templates, guidelines etc). For this I will create a setup using
Eclipse and employ springframework with struts for portlet development.
(The requirement to use struts already gives me headaches because of its
current incompatability with the portlet action/render render events. Anyone
who can help me out with this?).
I'd like to see a framework in Jetspeed for working with Struts portlets No one has championed this framework (yet)
We plan to support the entire recommended list in the spec
My initial questions concern the user and security implementation as is currently underway for jetspeed 2.
1) User attributes
Conform the portlet spec PLT.17.2 Jetspeed 2 should handle a predefined set of
user information attributes. Do you have
already a (minimum) set of attributes in mind which you are going to support?
And how?
To be able to store the user information attributes is it expected that aWe have a nice Preferences implementation in the works based on Java Preferences API with a database backend store
future usermanagement service will store/retrieve these attributes from the
user preferences or should I create my own UserAttributes class and link it
myself to the UserPrincipal?
The latter solution would be a (much) more optimzed storage (and largely
Jetspeed independant) but the first would allow easier customization.
The plan is to store portlet preferences using the Preference Store
2) Security
I want to use declaritive web security to enforce role access to portlets using
only one role.
My other security requirements are far to specific/proprietary to be able to
use your proposed security model (as specified in SecurityDesignNotes.txt)
fully (besides, the customer wants to be jetspeed independant as much as
possible).
Currently, declaritive web security is not yet handled by Jetspeed 2.
The Pluto deployer already does a better job by merging portlet.xml security
role requirements (not yet the security constraints) into the rewritten web.xml.
im taking note of that
But, that implementation, while enforcing declaritive role access on the
servlet when it would be called directly, doesn't have any effect AFAIK when
used within a portal as a PortletServlet will be included by a
RequestDispatcher and then these security constraints don't apply (SRV.12.2
Servlet spec 2.3).
And AFAIK no further security validation is done by Pluto (maybe this should be
a question for the pluto-dev team as well).
So my question is simple: what are your ideas and plans for implementing this
(as by portlet spec chapter PLT.20)?
In short we plan to support PLT.20 in full.
As of now the security is based on Java Security, and we will support both declarative security constraints from deployment descriptors and policies.
The basic programmatic security will of course be able to use Tomcat's or any other standard app server's authenticated principal.
Much like J1 but better standardized
I also noticed that both a Page and a Page Fragment define an acl attribute.
How is this attribute to be used?
The security policy defines security constraints (ACLs) on all portal resources such as pages and fragments
For now getting answers to these simple questions would do:-)
Finally let me thank you all for defining and building a great portal framework
and lets get it up and running!
Regards,
Ate
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
