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 Tue, 30 Sep 2003 02:24:17 GMT
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 <david@bluesunrise.com> wrote:
> 
> On Thursday, September 11, 2003, at 06:58  AM, David
> Le Strat wrote:
> 
> > 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.
> >
> 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
> 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!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Mime
View raw message