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]
