portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shub...@jahia.com>
Subject Re: Jetspeed 2 - Security/Profile Management.
Date Fri, 12 Sep 2003 11:33:17 GMT

Just a quick thought on the security / profile management ? Are there any 
new standards we should be looking at to implement ? Because they might 
impose some design choices, that might be difficult to adapt to afterwards. 
J2EE security shouldn't be a problem, but what about WSRP ?

Also, should portlets have a way to interact with the security / profile 
management ? For example to obtain a list of users to customize internal 
security, or should everything stay within the limits of the JSR-168 ?

   Serge Huber.

At 11:30 AM 9/11/2003 -0700, you 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
>>>>Jetspeed security, profile model.  I don't know if
>>>>anyone has already started the development
>>>Scott has started on something, but has not yet
>>>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
>>>>try to implement:
>>>>Goal: Separate security management from profile
>>>>management and provide an extensible profile
>>>>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
>>>>         - Hierarchical: Parent - Child group
>>>>relationship. Make it generic so that group -
>>>>relationship can be created at will.
>>>>         - Extensible: Jetspeed provides a Group
>>>>wrapper that wraps the security model (where the
>>>>group definition provide group id and group name)
>>>>a generic group extension (property_name,
>>>>property_value and maybe a way to track creation
>>>>modification dates) where users can create their
>>>>custom properties.
>>>Sounds a lot like J1 Groups, with two additions:
>>>hierarchies, custom
>>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
>>>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?
>We use Fulcrum but its wrapped with a CPS service layer.
>We'd like to replace Fulcrum with Avalon
>David Sean Taylor
>Bluesunrise Software
>+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

- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server

View raw message