> Chamberlain James O. CONTR J9C998 wrote: > > > I have been digging through the design documents and cvs looking at > > how the security is handled in Jetspeed 2. I am interested > in having > > Jetspeed authenticate & authorize against LDAP instead of > the database. > > Me too. > Considering Eve as the default Apache solution: > > http://incubator.apache.org/directory/subprojects/eve/
That's cool, I wasn't aware that Apache was working on a Java based LDAP solution. > > > One question that I have is: How will Jetspeed deal with > users being > > created, updated, and removed with it's knowledge? > > Im looking into writing an LDAP User Manager for J2 > > If for instance I > > hooked it to Active Directory and used the default AD tools > to admin > > the users and groups how would Jetspeed deal with these users and > > groups changing. First time a user logs into the portal would it > > auto-create the user's preferences, generate a default page > based off some template? > > Any issues in this area? > > Im just starting to prototype user creation, default pages, > profiles and user attributes. User attributes is an > interesting area. I was thinking that the user manager could > handle the mapping from the backend user > store(s) to the normalized user attributes made available to > the portal. I was thinking about implementing a user manager, but in my environment I would not be able to use it for write operations to the directory. Most likely I would be plugging the portal into a directory that I would not have direct control over and would be read-only for me. For instance if the portal was deployed company wide it would probably use a pre-existing Active Directory infrastructure. So I am wondering how well Jetspeed would function without any way of knowing when a new user is created or an existing user removed. Would default pages be created, would it break anything in the portal that would be counting on knowing when a user is created, updated, or removed? There are two camps in the portal community on how to handle external authentication / authorization: 1. Ones that can use external sources and can deal with users, groups, and roles changing without being notified and 2. Others that really need to know about those events and inturn replicate the data from the external source to internal databases. -James --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
