portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@douma.nu>
Subject Re: [J2]Building on Jetspeed 2
Date Wed, 10 Mar 2004 21:48:16 GMT
David Sean Taylor wrote:
> Wow this is a long one... ;-)

Sorry, got a bit carried away I think in trying to explain what I'm about
Thanks for taking the time anyway.
I've got some more questions below so thanks in advance also ;-)

> 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

Yeah, I noticed. Any idea when the persistency of it will be working (again)
so I can start playing around with it?

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

Well, I'm about to get my hands dirty on that one real soon so when I get
something working I will report back about it.
Still, if anyone else walked down this road before, it would be very nice to
get some hints about possible roadblocks and/or detours...

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

Alright I got that much from the source already.
But what about future usermanagement/registration (possibly ported from J1).
Do you intend to store standard user attributes like fullname, email etc.
also in the Preference Store or in a separate (still to be defined) user
object with its
own persistence definition?

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

Any ideas about a timeline for this?

> 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

Ok. So if I get this correctly, it will be based on your new user/group/role
security model.
Will role definitions defined through declaritive web security be
automatically mapped onto
this model?

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

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

View raw message