portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BaTien Duong <batien.du...@dbgroups.com>
Subject Re: Jetspeed 2 - Security/Profile Management.
Date Wed, 10 Sep 2003 18:23:47 GMT
David Le Strat wrote:

>Hello everyone,
>Just wanted to initiate a discussion around the new
>Jetspeed security, profile model.  I don't know if
>anyone has already started the development process.
>Here are some of the basic ideas I believe we should
>try to implement:
>Goal: Separate security management from profile
>management and provide an extensible profile structure
>at several levels.
>In detail:
>Groups: Provide an extensible hierarchical group
>        - Hierarchical: Parent - Child group
>relationship. Make it generic so that group - parent
>relationship can be created at will.
>        - Extensible: Jetspeed provides a Group
>wrapper that wraps the security model (where the base
>group definition provide group id and group name) and
>a generic group extension (property_name,
>property_value and maybe a way to track creation and
>modification dates) where users can create their
>custom properties.
>This provide a generic framework for users to extend
>the group model and use it for their business purpose.
>User: The same extensible concept outlined for groups
>applies to users. Jetspeed provides a user wrapper
>that wraps the security model (where the base user
>definition user_id, user_name, user_password and a way
>to track changes).  A generic user extension is also
>provided (property_name, proprety_value and tracking
>of changes).
>Therefore, the base Jetspeed profile model can easily
>be extended to implement specific requirements.
>A generic group / user extension could be provided in
>line with the Platform for Privacy Preferences
>User-Group Relationship: Users can be assigned to 1 or
>more groups.
>Roles: Additionally roles are necessary to manage
>entitlements and delegated administration where users
>and groups can be added to roles.
>In order to implement this in a flexible way, we
>should come up with a way to dynamically map to newly
>added properties.  For instance, we could access the
>extended profile/group through and
>getPropertyValue("property_name") type of accessor.
>This is a quick draft and hopefully it will be in line
>with what the Jetspeed team is trying to achieve.
>I am looking forward to your comments.  Best regards
>to all.
>David Le Strat.

I am just a starter and decided to work with Jetspeed-2.  In reviewing 
the JSR-168 specs, some important questions popped up:
    1)  Related to user profile and portlet preferences, can we extend 
the JSR-168 with the portlet context name/object rather than name/String 
or name/String[].  With the name/object pair  of PortletContext 
(PortletPreferences), we will be more aligned with WSRP.
    2) For the general pattern of action/context, is there any intention 
to incorporate commons *Chain of Responsibility* pattern in Jetspeed-2 
action/context design. I see the commons CoR a powerfull framework and 
will play a significant role in the design of all web tiers.
    3) Is there any intention to clearly separate Portal server from 
Portlet container? If people want to leverage on Tomcat, they can use 
Jetspeed portal server. If the company decides to use other portal 
server, they can just use Jetspeed portlet container.
    4) I hear discussion of some commiter(s) on the integration between 
Jetspeed and Slide for CMS. Is there any intention to include Slide 
authorization pattern of subject -> action -> object in the portlet 
context (PortletConfig) and preferences (PortletPreferences)?
    5) Is there any plan to integrate portlet container with SOAP server 
to enable portlet container as WSRP comsumer / producer?


View raw message