All, I have looked at this quite some more and have a few questions.
How much is it necessary in J2 to rely on PSML for user / groups definitions? My understanding is that PSML at the group / user /role level is mostly used for entitlements in J2. I am not quite sure where the media type plays for user/groups/roles with the page model. Shouldn't the page/presentation model take care of the presentation part whether it is html, wml or whatever other format? Therefore could we use a role based entitlement and rely on the Jetspeed security layer to manage resources ACL. Basically separate profile/user/group management from entitlement. I see several benefits from a clearer separation of those concerns. For instance, it is difficult to create any type of hierarchical group or role structure with the current scheme. I also feel the security concerns / user management concern / and presentation concern could be better separated that way. What are your thoughts? If you think this may be a good idea, let me know and I will be happy to draft a proposal. Best regards, David Le Strat. --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > On Thursday, September 11, 2003, at 06:58 AM, David > Le Strat wrote: > > > 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. > > > Recommend getting to know the code then. > > > > >> > >>> 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. > > > I like the idea of extensible profiles > > > > >> > >>> 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? > > > > > Yes, sure > We are simply using the old profiler in J2 with the > expectation that > someone will come along and step up and write a new > better one (ahem) > > >> 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. > > > Its up to the portal to try to put the attributes > requested by the > portlet app deployment descriptor into the user > attributes map > Attributes that can't be mapped are ignored > > > 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? > > > In your deployment descriptor, specify your > attributes as described in > PLT.17.1 Defining User Attributes > Which then map to the recommend attributing naming > in Appendix PLT.D > > > >> 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? > > No > We use Fulcrum but its wrapped with a CPS service > layer. > We'd like to replace Fulcrum with Avalon > > -- > 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!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
