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: Jetspeed 2 - Security/Profile Management.
Date Thu, 11 Sep 2003 03:14:35 GMT

On Wednesday, September 10, 2003, at 09:25  AM, 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.
>
Scott has started on something, but has not yet committed.
We welcome your new ideas!

> 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.
>
When you say separate security from profile management, I didn't 
realize they were coupled in J1

> 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.
Sounds a lot like J1 Groups, with two additions: hierarchies, custom 
properties

>
> This provide a generic framework for users to extend
> the group model and use it for their business purpose.
>

Have you any experience with writing either a Jetspeed Security service 
or a Jetspeed Profiler?
Are you familiar with the J1 profiler and security service code?

> 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).
>
Have you looked at the Java (TM) Portlet Specification?
See the section PLT.17 User Attributes

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

Thats new to me. I really like the concept and it seems like an 
important feature for a portal.

> 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.
>
I like the idea of extending the profiler.
I never thought we'd get so much mileage out of the first one.

> This is a quick draft and hopefully it will be in line
> with what the Jetspeed team is trying to achieve.
>
Remember that the portlet spec now defines a clean separation between 
the portlet application (your portlets) and the portal (Jetspeed).
What you have proposed seems to fall under the portal category.


--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
+01 707 529 9194


Mime
View raw message