David, Thanks for your explainations. Just found on Jetspeed site that currently it supports only following LDAP servers http://portals.apache.org/jetspeed-2/components/jetspeed-security/ldap.html.
- Apache DS <http://directory.apache.org/> - Open LDAP <http://www.openldap.org/> - Domino <http://www-306.ibm.com/software/lotus/> - Sun DS<http://www.sun.com/software/products/directory_srvr_ee/dir_srvr/index.xml> So i have to use one of these. It won't work with Windows Active Directory? On Thu, Dec 9, 2010 at 9:24 PM, David Taylor <[email protected]>wrote: > 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] > >
