attribute resolver issues after upgrade to v3

[Robert A Basch]

Hi.

We are just beginning to look at upgrading to IdP version 3, and have
encountered a couple of immediate issues with our existing attribute
resolver configuration.

In our version 2 attribute-resolver.xml, we have been using the
template language to effect a conditional query in an additional LDAP
data connector, based on the value (if any) of a dependency attribute:

    <FilterTemplate> 
        <![CDATA[ 
            #if (${attribute.isEmpty()} || ! ${attribute.get(0)})
              <dummy filter guaranteed to return no results> 
            #else 
              <"real" LDAP search filter> 
            #end 
        ]]> 
    </FilterTemplate>

In version 3, such a template does not work without modification.
By turning on debug logging, it looks like the problem is that the
whitespace around the search filters above is not being stripped, and
is resulting in the query throwing an exception:

2015-08-14 14:52:49,546 - ERROR
   [net.shibboleth.idp.profile.impl.ResolveAttributes:256] -
   Profile Action ResolveAttributes: Error resolving attributes
   net.shibboleth.idp.attribute.resolver.ResolutionException: Data
   Connector 'testLDAPConnector': Unable to execute LDAP search
	at net.shibboleth.idp.attribute.resolver.dc.ldap.impl.LDAPDataConnector.retrieveAttributes(LDAPDataConnector.java:148)
Caused by: org.ldaptive.LdapException:
   javax.naming.directory.InvalidSearchFilterException:
   Missing 'equals'; remaining name 'ou=[...],dc=edu'
        at org.ldaptive.provider.ProviderUtils.throwOperationException(ProviderUtils.java:77)
Caused by: javax.naming.directory.InvalidSearchFilterException:
   Missing 'equals'
        at com.sun.jndi.ldap.Filter.encodeSimpleFilter(Filter.java:330)

[lines wrapped for readability]

We found that we can avoid this error by removing all of the
whitespace around the filters within the template, e.g.:

    <FilterTemplate>
        <![CDATA[
            #if (${attribute.isEmpty()} || ! ${attribute.get(0)})
<dummy filter guaranteed to return no results>#else
<"real" LDAP search filter>#end
        ]]> 
    </FilterTemplate>

Another apparent change is in the handling of null values for the
dependency attributes we use.  These values come from an RDBMS data
connector (using the MySQL JDBC driver), where in some cases a null
value is indeed returned for one or more columns in the query.  In
version 2, a test like the one in the above template works fine to
detect a null value, but in version 3, the test fails, as the
attribute tested apparently has an actual "NULL_VALUE" value.  With
debug logging enabled, we see lines like this in the log:

2015-08-14 14:57:14,289 - DEBUG
   [net.shibboleth.idp.attribute.resolver.AbstractDataConnector:96] -
   Data Connector '<connector name>': Attribute '<attribute name>':
   Values '[EmptyAttributeValue{value=NULL_VALUE}]'

and

2015-08-14 14:57:14,401 - DEBUG
   [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:247] -
   Attribute Definition '<attribute name>': produced an attribute with the
   following values [EmptyAttributeValue{value=NULL_VALUE}]

I realize that there are better ways to do such things in version 3
(which we intend to look into), and we can clearly work around these
issues as needed, but I am wondering if this new behavior is expected,
or if either of these issues would be considered a bug.

Thanks,
Bob