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]



Reply via email to