portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: Jetspeed 2 - Security/Profile Management.
Date Thu, 11 Sep 2003 18:30:56 GMT

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?

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

View raw message