Thanks heap for the given inputs. I conclude that I need not implement a JNDIPrincipalStore that exposes password in order to serve my need. My need is the same as Kevin's; ie: to reuse the already authenticated user credentials, and the authentication is done against an LDAP server.
Following is the approach that I've been experimenting with. It uses JAASRealm. Please throw your comments before I'll propose to contribute the LoginModule I've written. In Tomcat's server.xml JAASRealm is set. As the LoginModule, we write one that whose Principal keeps the authenticated user credentials passed by CallbackHandler. When this LoginModule authenticates the user, it does it against an LDAP server whose configuration parameters are defined in jaas.config file. When working out the group and/or role where the user belongs, as SlideLoginModule does, it calls ACLSecurityImpl.getGroupMembership() so that Slide has the opportunity to set 'group-member-set' property in its users path. Jo.- ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <slide-dev@jakarta.apache.org> Sent: Friday, July 01, 2005 1:18 AM Subject: Re: JNDIPrincipalStore does not expose password > Yes that is true, the store does not get the credentials of the webapp > logged in user. I am wondering if I can change that in some elegant config > way (in tomcat or slide) or if I need to make code changes (in > JNDIPrincipalStore, create a security manager,...). I know I am not doing > something new here (webapp login using LDAP and Slide using LDAP), I just > have not figured out how others have done it. > > When you get a WebDav connection you need to supply a user/password to the > spec > _factory = (WebDAVConnectionFactory) ic.lookup( > java:comp/env/WebDAV-Connector);. > _spec = new WebDAVConnectionSpec(host, JAASSecurityUtil.getUsername(), > "operator", timeout); > > The Tomcat login is done via in the server.xml: > <Realm className="org.apache.catalina.realm.JNDIRealm" debug="99" > connectionURL="ldap://localhost:389"; > userPattern="uid={0},ou=People,dc=info,dc=org" > roleBase="ou=Roles,o=EastCoast,o=HQ,c=US,dc=info,dc=org" > roleName="cn" > roleSubtree="true" > roleSearch="uniqueMember={0}" > /> > > In general you have 2 servlets/webapps both doing a InitialDirContext to > bind to LDAP. I prefer not to prompt the user to enter their credentials > twice. > > > > > > Honoré David > <[EMAIL PROTECTED]> > To > 06/30/2005 10:42 Slide Developers Mailing List > AM <slide-dev@jakarta.apache.org> > cc > > Please respond to Subject > "Slide Developers Re: JNDIPrincipalStore does not > Mailing List" expose password > <[EMAIL PROTECTED] > a.apache.org> > > > > > > > > > There is one instance of the store to which all user connect ... and I > don't think that the store get the principal and credential of the logged > user which want to perform actions. > > [EMAIL PROTECTED] wrote: > I am using the JBoss/Tomcat 401 LDAPRealm and the Slide pre2.2 > JNDIPrincipalStore but can not get Slide to login without hardcoding > a > valid user/password. Any suggestions on how to reuse the already > authenticated user? I am not sure if I missed a configuration in > tomcat, > slide, or need to made a code change (in slide, create a security > manager > class, ...). If someone has this working could you give me some > help? > > > > > delbd > > <[EMAIL PROTECTED]> > > To > 06/30/2005 07:17 "Slide Developers Mailing > List" > AM <slide-dev@jakarta.apache.org> > > cc > > Please respond to > Subject > "Slide Developers Re: JNDIPrincipalStore does > not > Mailing List" expose password > > <[EMAIL PROTECTED] > > a.apache.org> > > > > > > > > > > Main reason to expose password in store would be to perform > authentification using > slideRealm. If this is your purpose simply use the LDAPRealm and you > won't > need to expose > password in slide while stille having users in your tomcat the same > as > users in slide. > > Le Jeudi 30 Juin 2005 04:14, Jo a écrit : > > Hi all, > > The documentation tells that JNDIPrincipalStore does not expose > password. > > I > > am wondering if there is a certain reason (design philosophy) > for this. I > > am > > thinking of implementing one that exposes password and would > like to know > whether there is a reason for not doing it. > > Thanks in advance for your input. > > Jo.- > > > > > > -------------------------------------------------------------- ------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > -- > David Delbecq > Royal Meteorological Institute of Belgium > > - > Is there life after /sbin/halt -p? > > -------------------------------------------------------------------- - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -------------------------------------------------------------------- - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --- > Antivirus avast! : message Entrant sain. > Base de donnees virale (VPS) : 0526-3, 30/06/2005 > Analyse le : 30/06/2005 16:38:24 > avast! - copyright (c) 1988-2005 ALWIL Software. > http://www.avast.com > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > !DSPAM:42c4101a230401028052192! > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
