Hello everyone,Howdy:
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 model. - 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 (http://www.w3c.org/TR/P3P).
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?
Thanks BaTien DBGROUPS
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
