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 ?

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

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



Mime
View raw message