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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
