On Tue, Dec 7, 2010 at 9:04 PM, anyz <[email protected]> wrote:
> Hi,
>
>
>
> I am assigned a task to work on Portal based upon Portlet 2.0 that will be
> deployed on Tomcat using Jetspeed 2.2.1. However in future this must be
> deployable on other portlet servers like IBM WebSphere. In first step I have
> to work out the possible security model for the application. Major
> requirements for security:
>
> -          Based on some standard
>
> -          Easily portable to Websphere or other server
>
> -          Two step security model in which authentication is done on
> cooperate network (LDAP or domain controller for example) than
> authorizations will be controlled by portlet server
>
Be careful with Jetspeed 2.2.1 LDAP:  a new LDAP impl was rewritten in
2.2, and the docs were never changed. The LDAP docs are not up-to-date
-- its really irresponsible .  I would not use the online docs for
reference, see the code and Spring configs instead.

To summarize, yes, we use our own schema for storing users. The 2.2
LDAP solution has a LDAP replicator - basically you point Jetspeed at
your LDAP, give it credentials and tell it which LDAP attributes to
replicate and map to our schema, and it periodically synchronizes the
LDAP attributes into the Jetspeed database


>
>
> So security must not dependent or tightly coupled with Jetspeed specific
> features. My initial understanding user must exists in portlet server
> (Jetspeed on this case) to control the authorization stuff(who can access
> and what can do). What could be best way these server independent so that
> these can be ported easily to other servers. Or for each server we have to
> re-create user/groups/roles using sort of admin interface that server
> provides.
>
The LDAP solution might work for you, since you can replicate the bits
you want. Jetspeed is based upon standard Java Security, JAAS, servlet
declarative security. So you have lots of standard choices without
needing to couple to the Jetspeed Security APIs, although that is an
option too.

We have written custom authentication solutions, usually following a
pattern that combines a filter and jetspeed valve to  populate the
required Jetspeed Subject in the request, examples:

http://portals.apache.org/jetspeed-2/guides/guide-tomcat-sso-cross-context-j2-realm.html
http://portals.apache.org/jetspeed-2/deployguide/config-sso.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to