portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Le Strat <dlest...@yahoo.com>
Subject Re: Jetspeed 2 - Security/Profile Management.
Date Thu, 11 Sep 2003 13:58:50 GMT
Please see some additional comments below.

--- David Sean Taylor <david@bluesunrise.com> wrote:
> 
> 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!

Thanks for the welcoming. Please keep in mind that I
have a limited knowledge of J1.  From having a quick
look at J1, I am aware that a lot of work has already
be done in that area.


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

This is just a generic goal statement not an
assessment of previous work. Knowing the quality of
your work, I am sure the separation has already been
achieved in J1.  Here I just want to point out the
separation between a generic baseline profile
(probably only id, username, password) and a set of
dynamic properties that can be used for extending the
profile with additional attributes.


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

Any interest in implementing this in J2?


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

Not very much so, but I am learning.


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

I actually looked into it.  The link between the
portal framework and the portlet user attributes is
not very clear reading the specs.

Let say, that in my portlet I can abstract my portlet
user attributes from the portal framework user
definition.  Where do I map the portlet defined
attributes to the portal framework ones?


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

This is also mentioned in the JSR168 specs in PLT.D



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

That's the mark of a good design. ;o)



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


Definitely, this email falls under the portal
framework side. 

I am looking forward to suggestion on how best to help
out on this.  I noticed looking at J1 codes that the
profiler and security layers rely a lot on Turbine
services.  As part of J2, will you still rely on the
Turbine services?

Best regards,

David Le Strat.
 
> 
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
> +01 707 529 9194
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Mime
View raw message