portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Jetspeed-2.2: major refactoring of the security model and api ahead
Date Fri, 29 Aug 2008 14:26:06 GMT
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

We will be working together on realizing the above goals the next few weeks in the new "security-refactoring"
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,


To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message