> > It is my understanding that the user on the ProfileLocator is > the owner > of the PSML document -- not necessarily the user currently > logged in. true > want an admin user to be able to log in and make a change that affects > other users. In a corporate setting, this sort of change is fairly > common. > > > > It would be easy to add a single parameter to all methods - > > perhaps RunData would be more useful although it ties the > > methods to rundata requests. > > > > Do you plan on integrating it with Turbine Security? > > There has been a lot of talk on the mailing list, but I don't > > think the Turbine folks ever got around to actually > > implementing a Turbine LDAP Security Service. > > I am indeed planning on integrating it with TurbineSecurity, > which also > seems to have no notion of the currently logged-in user once > you get to > methods like addRole(). I expect that I will have to extend the > TurbineSecurity and TurbineSecurityService interfaces, to add user or > rundata objects to every method where a secure function is > performed. I > re-bind to the LDAP server for each secure call. Perhaps > this should be > reconsidered? > look at the JetspeedSecurityService interface and its impl: JetspeedDBSecurityService. It has methods that need rundata such as addUser( User user, String password, RunData data ) > > > > I would think that if you are going to store PSML in LDAP, > > then you would want to also store the user info there. > > I am storing user info in LDAP. I guess its not clear to me. Are you persisting the Jetspeed/Turbine Security user info to LDAP? Or do you have two user databases, one in LDAP, and another in Jetspeed's user database. > > In response to a couple of additional questions from Raphael's message > (to keep this thread simple): > > - I don't need to be able to read the user password from LDAP; I just > need to be able to send a user's credentials and verify that the user > can be authenticated. > > - I am not using a database. > > - I want my LDAP binding to be user-related -- I don't want the > application to be able to access LDAP without the credentials of a > current user. To do this, I believe that the binding has to be either > on the session or recreated for each secure function. For > now, I chose > to go with the approach of rebinding for each secure function. > > Thank you for your help on this. > > -mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
<<attachment: winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
