I solved problem for us by using attributes. Since I needed to return a few attributes anyway, I mapped the attribute 'username' to a specific directory attribute. In my case, this has the effect of returning the data from the directly instead of what the user typed.
It still requires that I configure an account that can retrieve the attributes once a user has successfully logged in. -John -----Original Message----- From: Tom Poage [mailto:[email protected]] Sent: Friday, February 21, 2014 2:14 PM To: [email protected] Subject: Re: [cas-user] LDAP: Bind vs FastBind On 02/21/2014 05:24 AM, Whittaker, Geoffrey wrote: > What are the benefits of FastBind over Bind. Are there any security > issues I should be aware of if I use FastBind? With the general case-insensitive nature of LDAP queries, we discovered the need to 'normalize' and filter the username when using "fast bind" (not AD). The username/principal is exposed through service ticket validation as entered at the login page, so if the client enters "Fred" one time and "FRED" another, it'll match the same LDAP entry, but to any case-sensitive app downstream, it looks like two different clients. Ended up implementing a CredentialsToPrincipalResolver: > protected String extractPrincipalId(final Credentials credentials) { > final UsernamePasswordCredentials usernamePasswordCredentials = > (UsernamePasswordCredentials) credentials; > return usernamePasswordCredentials.getUsername().trim().toLowerCase(); > } See my post from November 13, 2013 for details (added trim() since). A newer version of ldaptive also encodes the argument so someone can't try any funny stuff with the bind DN. Tom. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
