To include differnt LDAP servers we can need to write our own security layer using JAAS or SpringSecurity? In this case we also need to keep LDAP and Jetspeed synchronized as new users/groups are added/deleted. I am exploring but i guess for this synchronization Jetspeed will be providing APIs.
Thanks On Mon, Dec 13, 2010 at 10:51 AM, anyz <[email protected]> wrote: > 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] >> >> >
