We don't share contexts across the different resolvers and authentication handlers as they have no knowledge of each other (which is by design since they each run independently of the others).
You should be obtaining the appropriate context in each one. If you use LDAP pooling then there is minimal (i.e. almost none) penalty for rebinding (we ran some load tests on this) -Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Thu, Jul 31, 2008 at 4:13 PM, <[EMAIL PROTECTED]> wrote: > > Scott, > > I'm not looking up attributes in the Authentication Handler. Not resolving > the principal or populating the meta data. > > Leaving those to be dealt with by their respective handlers. > > What I am doing is putting the user's login and password into the Context > so that when the CredentialsToPrincipalResolver and the > AuthenticationMetaDataPopulator do their binds, they do so with the user's > login and password rather than anonymously > . > > Thanks, > Ann > > ------ > G. Ann Campbell > Systems Engineer > Shaw Industries > > > > > *"Scott Battaglia" <[EMAIL PROTECTED]>* > Sent by: [EMAIL PROTECTED] > > 07/31/2008 03:55 PM > Please respond to > Yale CAS mailing list <[email protected]> > > To > "Yale CAS mailing list" <[email protected]> > cc > Subject > Re: LDAP fastbind + non-anonymous principal lookup - again > > > > > The validation of credentials and the eventual resolution to a principal > are two separate actions. > > Nothing precludes you from binding to a Context and retrieving attributes > you just don't do it in the AuthenticationHandler, which is used to > authenticate that the provided credentials are valid. > > If you try and do stuff in the wrong section of course its going to feel > like a hack. Take a look at the CredentialsToPrincipalResolver which you'll > notice actually returns a Principal whereas the AuthenticationHandler merely > returns true or false. > > -Scott > > -Scott Battaglia > PGP Public Key Id: 0x383733AA > LinkedIn: > *http://www.linkedin.com/in/scottbattaglia*<http://www.linkedin.com/in/scottbattaglia> > > > On Thu, Jul 31, 2008 at 3:48 PM, <[EMAIL PROTECTED]<[EMAIL PROTECTED]>> > wrote: > > I have to pose a question that my colleagues and I have been asking each > other for a few days now: > > If you have user-provided credentials that authenticate against a > directory, why _wouldn't_ you use them for principal lookup and attribute > retrieval? Just by default? I'm not trying to be smarmy here. I'd really > like to understand this from an architectural standpoint. > > Also, it _looks_ like an easy way out in FastBindLdapAuthenticationHandler > (or some variation thereof) to set the user's credentials into the > Context's UserDn and Password. It works like a champ, but it _feels_ like a > bad idea. > > I'm only setting the credentials into the Context after successful login > and I'm resetting them to empty string at the top of the > authenticateUsernamePasswordInternal routine to minimize the chance that > userB could ride userA's coattails into the system. But I have a lingering > sense of doubt. > > Thoughts? Please? I'm looking for an elegant way to handle this, but what > I've come up with feels like a hack. > > > Thanks, > Ann > > ------ > G. Ann Campbell > Systems Engineer > Shaw Industries > > ********************************************************** > Privileged and/or confidential information may be contained in this > message. If you are not the addressee indicated in this message (or are not > responsible for delivery of this message to that person) , you may not copy > or deliver this message to anyone. In such case, you should destroy this > message and notify the sender by reply e-mail. > If you or your employer do not consent to Internet e-mail for messages of > this kind, please advise the sender. > Shaw Industries does not provide or endorse any opinions, conclusions or > other information in this message that do not relate to the official > business of the company or its subsidiaries. > ********************************************************** > > > _______________________________________________ > Yale CAS mailing list* > [EMAIL PROTECTED] <[email protected]>* > **http://tp.its.yale.edu/mailman/listinfo/cas*<http://tp.its.yale.edu/mailman/listinfo/cas> > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > > ********************************************************** > Privileged and/or confidential information may be contained in this message. > If you are not the addressee indicated in this message (or are not > responsible for delivery of this message to that person) , you may not copy > or deliver this message to anyone. In such case, you should destroy this > message and notify the sender by reply e-mail. > If you or your employer do not consent to Internet e-mail for messages of > this kind, please advise the sender. > Shaw Industries does not provide or endorse any opinions, conclusions or > other information in this message that do not relate to the official business > of the company or its subsidiaries. > ********************************************************** > > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
