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


Mime
View raw message