You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2008/08/29 16:26:06 UTC
Jetspeed-2.2: major refactoring of the security model and api ahead
David Taylor, Vivek Kumar, Woonsan Ko, Dennis Dam and myself have been discussing some major steps for improving and
enhancing the Jetspeed Security API and integration support for external authorization providers (like LDAP).
While we're still underway with refactoring out the Java Preferences usage (JS2-869), there are several other parts of
our current security model and api which are are not as easy in usage and configuration or extendable and customizable
as we would like it to be (see for example JS2-870, JS2-872 and JS2-873).
Our primary goals for the next major steps in solving these issues are:
- Flattening the principal API and model:
currently Jetspeed uses 3 separate object layers for this, for example User, UserPrincipal and InternalUserPrincipal
the goal is to collapse these three layers back into one
- Allow pluggable extensions to, or even completely new, (Jetspeed)Principal types besides the currently supported
User, Group and Role principals.
Support for security (principal) entities like Organization, Project, Workspace etc. should be easily added without
impacting the core security API and allow *transparent* usage of it out of the box (like with the JetspeedSerializer)
- Associations between principals are currently managed within the code and configuration (separate "table" for each).
With future (yet unknown) Principals to be added to the security layer, a flexible association solution is needed.
- Full external authorization provider support (like LDAP).
The current LDAP support is not complete (like permissions or preferences/attributes cannot yet be mapped to LDAP),
and the abstractions put in place to support different back ends has impacted the API
(least common denominator effect).
We need a new solution which allows *transparent* support for an external authorization provider while keeping our
core security API clean and simple (see also the first bullet)
- As solution for the above goal, we've decided the best way to resolve it is basing our new security api and model
*only* on the database engine (allowing for a much more efficient and effective API), and providing integration with-
an external authorization provider through synchronization and replication only.
This means: from Jetspeed POV at runtime it *only* looks at the database for authorization (not authentication).
- Last but not least, the above goals *will* have a major impact on both the core security API, the database model and
the configurations.
But, we will strive to refactor the current main security APIs (User, Role, Group, Permission, and their Managers)
as much as possible back to (or on top of) the new API to keep the impact minimal as we can.
We will be working together on realizing the above goals the next few weeks in the new "security-refactoring" branch
which itself is branched off the JS2-869 branch. Once this new branch stabilizes out we intend to merge (or swap) it
with the trunk.
And, after getting the new security model and api working, there are only a few additional changes we'd like to get done
before starting with putting out the jetspeed 2.2 release:
- Pluto 2.0 integration (see: JS2-871)
- replace OJB with OpenJPA (unsure: might need to be pushed back to after jetspeed-2.2)
And still, with all of that, our target for the 2.2 release is before (or at) ApacheConUS 2008 (November this year) :)
Any support and feedback will be very much appreciated.
With regards,
Ate,
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Jetspeed-2.2: major refactoring of the security model and api ahead
Posted by David Sean Taylor <da...@bluesunrise.com>.
Hi Ate,
Good luck !
On Aug 29, 2008, at 2:10 PM, Ate Douma wrote:
> Hi David,
>
> See comment inline below.
>
> Regards,
>
> Ate
>
> David Sean Taylor wrote:
>> The cross post got me. I meant for this to go to jetspeed-dev.
>> Begin forwarded message:
>>> From: David Sean Taylor <da...@bluesunrise.com>
>>> Date: August 29, 2008 11:58:28 AM PDT
>>> To: "Jetspeed Users List" <je...@portals.apache.org>
>>> Subject: Re: Jetspeed-2.2: major refactoring of the security model
>>> and api ahead
>>> Reply-To: "Jetspeed Users List" <je...@portals.apache.org>
>>>
>>> Ate,
>>>
>>> Im just getting back online after a few days without my main
>>> computer.
>>> Shouldn't we be merging back JS2-869, and then branching the
>>> security-refactoring off of that ?
> Yes we could that, but the JS2-869 branch still contains some issues
> such that in its current state it isn't really usable or runnable as
> a complete portal.
>
> I prefer we keep the current trunk, which *is* pretty stable right
> now, to allow others to test the new maven-2 build system properly.
>
> The issues I noticed with the JS2-869 branch are within areas which
> will be part of the tasks for the security-refactoring branch, so
> they will be picked up and dealt with automatically there.
>
:-)
>
> Once the security-refactoring branch stabilizes out, I propose we
> simply *replace* the current trunk with it (saving it first a pre-
> merge-security-refactoring branch) instead of trying to merge all
> the changes back, which would be a very cumbersome and error prone
> task.
> To be able to do this though will require us to synchronize every
> (needed) update/fix on the current trunk also to be applied to the
> branch (as I have been doing for the JS2-869 branch before).
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Jetspeed-2.2: major refactoring of the security model and api ahead
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Aug 29, 2008, at 2:10 PM, Ate Douma wrote:
>>>> We will be working together on realizing the above goals the next
>>>> few weeks in the new "security-refactoring" branch which itself
>>>> is branched off the JS2-869 branch. Once this new branch
>>>> stabilizes out we intend to merge (or swap) it with the trunk.
>>>>
Ah I missed that on first read. Good. Im OK with the security
refactoring plan as its based off of 869.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Fwd: Jetspeed-2.2: major refactoring of the security model and
api ahead
Posted by Ate Douma <at...@douma.nu>.
Hi David,
See comment inline below.
Regards,
Ate
David Sean Taylor wrote:
> The cross post got me. I meant for this to go to jetspeed-dev.
>
> Begin forwarded message:
>
>> From: David Sean Taylor <da...@bluesunrise.com>
>> Date: August 29, 2008 11:58:28 AM PDT
>> To: "Jetspeed Users List" <je...@portals.apache.org>
>> Subject: Re: Jetspeed-2.2: major refactoring of the security model and
>> api ahead
>> Reply-To: "Jetspeed Users List" <je...@portals.apache.org>
>>
>> Ate,
>>
>> Im just getting back online after a few days without my main computer.
>> Shouldn't we be merging back JS2-869, and then branching the
>> security-refactoring off of that ?
Yes we could that, but the JS2-869 branch still contains some issues such that in its current state it isn't really
usable or runnable as a complete portal.
I prefer we keep the current trunk, which *is* pretty stable right now, to allow others to test the new maven-2 build
system properly.
The issues I noticed with the JS2-869 branch are within areas which will be part of the tasks for the
security-refactoring branch, so they will be picked up and dealt with automatically there.
Once the security-refactoring branch stabilizes out, I propose we simply *replace* the current trunk with it (saving it
first a pre-merge-security-refactoring branch) instead of trying to merge all the changes back, which would be a very
cumbersome and error prone task.
To be able to do this though will require us to synchronize every (needed) update/fix on the current trunk also to be
applied to the branch (as I have been doing for the JS2-869 branch before).
>>
>> On Aug 29, 2008, at 7:26 AM, Ate Douma wrote:
>>
>>> David Taylor, Vivek Kumar, Woonsan Ko, Dennis Dam and myself have
>>> been discussing some major steps for improving and enhancing the
>>> Jetspeed Security API and integration support for external
>>> authorization providers (like LDAP).
>>>
>>> While we're still underway with refactoring out the Java Preferences
>>> usage (JS2-869), there are several other parts of our current
>>> security model and api which are are not as easy in usage and
>>> configuration or extendable and customizable as we would like it to
>>> be (see for example JS2-870, JS2-872 and JS2-873).
>>>
>>> Our primary goals for the next major steps in solving these issues are:
>>>
>>> - Flattening the principal API and model:
>>> currently Jetspeed uses 3 separate object layers for this, for
>>> example User, UserPrincipal and InternalUserPrincipal
>>> the goal is to collapse these three layers back into one
>>>
>>> - Allow pluggable extensions to, or even completely new,
>>> (Jetspeed)Principal types besides the currently supported
>>> User, Group and Role principals.
>>> Support for security (principal) entities like Organization, Project,
>>> Workspace etc. should be easily added without
>>> impacting the core security API and allow *transparent* usage of it
>>> out of the box (like with the JetspeedSerializer)
>>>
>>> - Associations between principals are currently managed within the
>>> code and configuration (separate "table" for each).
>>> With future (yet unknown) Principals to be added to the security
>>> layer, a flexible association solution is needed.
>>>
>>> - Full external authorization provider support (like LDAP).
>>> The current LDAP support is not complete (like permissions or
>>> preferences/attributes cannot yet be mapped to LDAP),
>>> and the abstractions put in place to support different back ends has
>>> impacted the API
>>> (least common denominator effect).
>>> We need a new solution which allows *transparent* support for an
>>> external authorization provider while keeping our
>>> core security API clean and simple (see also the first bullet)
>>>
>>> - As solution for the above goal, we've decided the best way to
>>> resolve it is basing our new security api and model
>>> *only* on the database engine (allowing for a much more efficient and
>>> effective API), and providing integration with-
>>> an external authorization provider through synchronization and
>>> replication only.
>>> This means: from Jetspeed POV at runtime it *only* looks at the
>>> database for authorization (not authentication).
>>>
>>> - Last but not least, the above goals *will* have a major impact on
>>> both the core security API, the database model and
>>> the configurations.
>>> But, we will strive to refactor the current main security APIs (User,
>>> Role, Group, Permission, and their Managers)
>>> as much as possible back to (or on top of) the new API to keep the
>>> impact minimal as we can.
>>>
>>> We will be working together on realizing the above goals the next few
>>> weeks in the new "security-refactoring" branch which itself is
>>> branched off the JS2-869 branch. Once this new branch stabilizes out
>>> we intend to merge (or swap) it with the trunk.
>>>
>>> And, after getting the new security model and api working, there are
>>> only a few additional changes we'd like to get done before starting
>>> with putting out the jetspeed 2.2 release:
>>> - Pluto 2.0 integration (see: JS2-871)
>>> - replace OJB with OpenJPA (unsure: might need to be pushed back to
>>> after jetspeed-2.2)
>>>
>>> And still, with all of that, our target for the 2.2 release is before
>>> (or at) ApacheConUS 2008 (November this year) :)
>>> Any support and feedback will be very much appreciated.
>>>
>>> With regards,
>>>
>>> Ate,
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Fwd: Jetspeed-2.2: major refactoring of the security model and api ahead
Posted by David Sean Taylor <da...@bluesunrise.com>.
The cross post got me. I meant for this to go to jetspeed-dev.
Begin forwarded message:
> From: David Sean Taylor <da...@bluesunrise.com>
> Date: August 29, 2008 11:58:28 AM PDT
> To: "Jetspeed Users List" <je...@portals.apache.org>
> Subject: Re: Jetspeed-2.2: major refactoring of the security model
> and api ahead
> Reply-To: "Jetspeed Users List" <je...@portals.apache.org>
>
> Ate,
>
> Im just getting back online after a few days without my main computer.
> Shouldn't we be merging back JS2-869, and then branching the
> security-refactoring off of that ?
>
> On Aug 29, 2008, at 7:26 AM, Ate Douma wrote:
>
>> David Taylor, Vivek Kumar, Woonsan Ko, Dennis Dam and myself have
>> been discussing some major steps for improving and enhancing the
>> Jetspeed Security API and integration support for external
>> authorization providers (like LDAP).
>>
>> While we're still underway with refactoring out the Java
>> Preferences usage (JS2-869), there are several other parts of our
>> current security model and api which are are not as easy in usage
>> and configuration or extendable and customizable as we would like
>> it to be (see for example JS2-870, JS2-872 and JS2-873).
>>
>> Our primary goals for the next major steps in solving these issues
>> are:
>>
>> - Flattening the principal API and model:
>> currently Jetspeed uses 3 separate object layers for this, for
>> example User, UserPrincipal and InternalUserPrincipal
>> the goal is to collapse these three layers back into one
>>
>> - Allow pluggable extensions to, or even completely new,
>> (Jetspeed)Principal types besides the currently supported
>> User, Group and Role principals.
>> Support for security (principal) entities like Organization,
>> Project, Workspace etc. should be easily added without
>> impacting the core security API and allow *transparent* usage of it
>> out of the box (like with the JetspeedSerializer)
>>
>> - Associations between principals are currently managed within the
>> code and configuration (separate "table" for each).
>> With future (yet unknown) Principals to be added to the security
>> layer, a flexible association solution is needed.
>>
>> - Full external authorization provider support (like LDAP).
>> The current LDAP support is not complete (like permissions or
>> preferences/attributes cannot yet be mapped to LDAP),
>> and the abstractions put in place to support different back ends
>> has impacted the API
>> (least common denominator effect).
>> We need a new solution which allows *transparent* support for an
>> external authorization provider while keeping our
>> core security API clean and simple (see also the first bullet)
>>
>> - As solution for the above goal, we've decided the best way to
>> resolve it is basing our new security api and model
>> *only* on the database engine (allowing for a much more efficient
>> and effective API), and providing integration with-
>> an external authorization provider through synchronization and
>> replication only.
>> This means: from Jetspeed POV at runtime it *only* looks at the
>> database for authorization (not authentication).
>>
>> - Last but not least, the above goals *will* have a major impact on
>> both the core security API, the database model and
>> the configurations.
>> But, we will strive to refactor the current main security APIs
>> (User, Role, Group, Permission, and their Managers)
>> as much as possible back to (or on top of) the new API to keep the
>> impact minimal as we can.
>>
>> We will be working together on realizing the above goals the next
>> few weeks in the new "security-refactoring" branch which itself is
>> branched off the JS2-869 branch. Once this new branch stabilizes
>> out we intend to merge (or swap) it with the trunk.
>>
>> And, after getting the new security model and api working, there
>> are only a few additional changes we'd like to get done before
>> starting with putting out the jetspeed 2.2 release:
>> - Pluto 2.0 integration (see: JS2-871)
>> - replace OJB with OpenJPA (unsure: might need to be pushed back to
>> after jetspeed-2.2)
>>
>> And still, with all of that, our target for the 2.2 release is
>> before (or at) ApacheConUS 2008 (November this year) :)
>> Any support and feedback will be very much appreciated.
>>
>> With regards,
>>
>> Ate,
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-
>> help@portals.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
Re: Jetspeed-2.2: major refactoring of the security model and api ahead
Posted by David Sean Taylor <da...@bluesunrise.com>.
Ate,
Im just getting back online after a few days without my main computer.
Shouldn't we be merging back JS2-869, and then branching the security-
refactoring off of that ?
On Aug 29, 2008, at 7:26 AM, Ate Douma wrote:
> David Taylor, Vivek Kumar, Woonsan Ko, Dennis Dam and myself have
> been discussing some major steps for improving and enhancing the
> Jetspeed Security API and integration support for external
> authorization providers (like LDAP).
>
> While we're still underway with refactoring out the Java Preferences
> usage (JS2-869), there are several other parts of our current
> security model and api which are are not as easy in usage and
> configuration or extendable and customizable as we would like it to
> be (see for example JS2-870, JS2-872 and JS2-873).
>
> Our primary goals for the next major steps in solving these issues
> are:
>
> - Flattening the principal API and model:
> currently Jetspeed uses 3 separate object layers for this, for
> example User, UserPrincipal and InternalUserPrincipal
> the goal is to collapse these three layers back into one
>
> - Allow pluggable extensions to, or even completely new,
> (Jetspeed)Principal types besides the currently supported
> User, Group and Role principals.
> Support for security (principal) entities like Organization,
> Project, Workspace etc. should be easily added without
> impacting the core security API and allow *transparent* usage of it
> out of the box (like with the JetspeedSerializer)
>
> - Associations between principals are currently managed within the
> code and configuration (separate "table" for each).
> With future (yet unknown) Principals to be added to the security
> layer, a flexible association solution is needed.
>
> - Full external authorization provider support (like LDAP).
> The current LDAP support is not complete (like permissions or
> preferences/attributes cannot yet be mapped to LDAP),
> and the abstractions put in place to support different back ends
> has impacted the API
> (least common denominator effect).
> We need a new solution which allows *transparent* support for an
> external authorization provider while keeping our
> core security API clean and simple (see also the first bullet)
>
> - As solution for the above goal, we've decided the best way to
> resolve it is basing our new security api and model
> *only* on the database engine (allowing for a much more efficient
> and effective API), and providing integration with-
> an external authorization provider through synchronization and
> replication only.
> This means: from Jetspeed POV at runtime it *only* looks at the
> database for authorization (not authentication).
>
> - Last but not least, the above goals *will* have a major impact on
> both the core security API, the database model and
> the configurations.
> But, we will strive to refactor the current main security APIs
> (User, Role, Group, Permission, and their Managers)
> as much as possible back to (or on top of) the new API to keep the
> impact minimal as we can.
>
> We will be working together on realizing the above goals the next
> few weeks in the new "security-refactoring" branch which itself is
> branched off the JS2-869 branch. Once this new branch stabilizes out
> we intend to merge (or swap) it with the trunk.
>
> And, after getting the new security model and api working, there are
> only a few additional changes we'd like to get done before starting
> with putting out the jetspeed 2.2 release:
> - Pluto 2.0 integration (see: JS2-871)
> - replace OJB with OpenJPA (unsure: might need to be pushed back to
> after jetspeed-2.2)
>
> And still, with all of that, our target for the 2.2 release is
> before (or at) ApacheConUS 2008 (November this year) :)
> Any support and feedback will be very much appreciated.
>
> With regards,
>
> Ate,
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org