LDAP connection error causes resolver to fail

[Terry Fleury]

Thanks for the heads up Keith. I've changed my attribute-resolver.xml to
prefer 'uid' from LDAP, with a FailoverConnector which calculates uid
from the JAAS principal. (This also eliminates the hacky single space
static attribute that I had before.) So the vast majority of the time,
the uid for eppn calculation will be the sanitized version from LDAP.

-Terry

On 2017-06-08 4:08 PM, Wessel, Keith wrote:
> Terry,
> 
> FWIW, use a bit of caution when mapping the entered principal directly to a uid or eppn attribute. With certain Kerberos implementations, it's possible for the user to enter mixed-case usernames or even punctuation after their user name that gets ignored by the Kerberos layer but passed through to the attribute resolver. The result is that the real user is authenticated, but a variation of the username is mapped to the attribute and you now have a user in an application with two different identities.
> 
> The hooks available in V3 for performing regex replacements on the principal help if you're willing to keep finding all of the permutations users can come up with. We finally gave up and just started mapping the unique UID (sAMAccountName in our case) attribute to uid and eppn as it's guaranteed to be consistent despite Kerberos's handling of different values.
> 
> Keith
> 
> 
> -----Original Message-----
> From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Terry Fleury
> Sent: Thursday, June 08, 2017 3:37 PM
> To: Shib Users <users at shibboleth.net>; Cantor, Scott <cantor.2 at osu.edu>
> Subject: Re: LDAP connection error causes resolver to fail
> 
> On 2017-06-08 2:32 PM, Cantor, Scott wrote:
> 
> --- snip ---
> 
>> The main piece is the property in services.properties that masks resolver failure. I won't argue whether the default is good or bad, but it's there to be changed if you prefer. As for whether returning an error to the SP makes sense, well, I doubt it. But YMMV. Anyway, you can do it.
> 
> Thanks, I was not aware of this setting. I'll test it out.
> 
> --- snip ---
> 
>> If you want data to be resolved even if LDAP is down, then the issue is in the resolver, making sure you have failure settings configured right, and possibly providing a failover connector. If you want an error, then the mask property in the services.properties file will help with that.
> 
> A failover connector with static values seems to work. I had to set the
> values of the static connector attributes to a single space (" "), which
> isn't exactly correct, but I understand the rest of the attributes need
> to have some data to work with. This solution might be 'good enough'.
> 
> Thanks for your help, Scott.
> 
> -Terry
>