Please see some additional comments below. --- David Sean Taylor <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > +01 707 773-4646 > +01 707 529 9194 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
