portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J2]Building on Jetspeed 2
Date Wed, 10 Mar 2004 19:07:42 GMT
Wow this is a long one... ;-)

On Tuesday, March 9, 2004, at 12:42  PM, ate@douma.nu wrote:

> Hello jetspeed 2 team!
>
> 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 :-)
>
me too ;)

> The coming weeks/months I probably will bug you a lot but I'm also 
> allowed to
> 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)
>
layouts in jetspeed-2 are portlets
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

> - 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
>
yes, we will need to port many of the J1 administrative portlets to J2 
and as Portlet API compliant
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)

>
> 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?
>
We plan to support the entire recommended list in the spec

> To be able to store the user information attributes is it expected 
> that a
> 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.
>
We have a nice Preferences implementation in the works based on Java 
Preferences API with a database backend store
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.

>
> I also noticed that both a Page and a Page Fragment define an acl 
> attribute.
> How is this attribute to be used?
>
Much like J1 but better standardized
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: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>


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


Mime
View raw message