A SiteMinder User Directory object allows you to configure which attribute it will use to search an LDAP directory when a user tries to authenticate. But there is no place in there to create a complex LDAP query that uses OR logic. So that means that there’s no way to allow your users to enter either their uid or their email address during authentication right? Wrong. This request comes up from time to time. Sometimes because our customer has some users who chronically forget their uid. Or maybe not all users have a uid as soon as they are provisioned. In this article, we will discuss the best way to overcome the single attribute limitation of the User Directory lookup.
The uninteresting way to accomplish this is to create two User Directory objects; one that looks up users based on uid, and another that looks up users based on email and then add them both to your Domain. So let’s say you do that, and you put the one that looks up uid’s first in the search order. If the user enters their email address firstname.lastname@example.org then SiteMinder will try the first directory object, it will issue a search for email@example.com, which of course will yield 0 results. It will move on to the second directory object, issue a search for firstname.lastname@example.org and hopefully find him. The obvious drawback to this approach is that every time the user enters their email address, a futile search goes to your LDAP for uid first. If your site is high-load, this can have a sizable impact on performance. Another downside to this approach is that you will have to do double-duty in all of your policies, adding the same users from both User Directory objects.
But what good is a blog article that only has boring solutions that everyone already knows? Let’s get to the interesting stuff…
Upon a forms post to an fcc file, the WebAgent passes to the Policy Server the “username” field. The username field is controlled by the @username directive at the top of your fcc. By default it looks like this:
%USER% refers to the form field where the user inputs their username.
So by default it just passes the username, like jdoe.
Typically, the User Directory Lookup Start and End look like:
So when the WebAgent passes jdoe the resultant search is (uid=jdoe).
But what if we told the WebAgent to send a little more across, and put less in the User Directory Lookup Start and End?
Starting simple, just change the fcc’s top line to:
And then update your User Directory to look like:
Now the WebAgent passes uid=jdoe and the Policy Server only puts the parentheses around it, and the resultant search is, once again, (uid=jdoe).
See where I’m going with this yet?
Since we can’t ask a single User Directory on the Policy Server to lookup the user by two different attributes, we intelligently control the attribute from the WebAgent side.
First we create two new fcc’s.
passuid.fcc has the following first line:
passemail.fcc has the following first line:
Hopefully you’re already using a non-fcc dynamic page (asp/aspx/jsp) as your login page, which posts to the fcc.
Now you put some text on your login form, letting users know that they can enter either their uid or their email address.
Then you add some code to that login page to dynamically select which fcc to post to.
if <username field contains @ symbol>
then POST to passemail.fcc
else POST to passuid.fcc
NOTE: You have to post all of the other necessary elements as well; TARGET, AGENTNAME, etc.
If the user enters just jdoe in the form field, the login form will post to passuid.fcc and the WebAgent will pass uid=jdoe to the Policy Server.
If the user enters email@example.com in the form field, the login form will post to passemail.fcc and the WebAgent will pass firstname.lastname@example.org to the Policy Server.
The Policy Server will surround it with parentheses, and send the search.
You can now allow users to enter either a uid or an email address to login, and still use only a single User Directory object on the Policy Server side.