IdP 3.4.3 attribute-resolver.xml LDAP DataConnector errors

[Glanville, Peter C.]

I may have a misunderstanding related to how these two mechanisms work then, but I think this conversation just clarified it. My understanding is below. 

There are two different flows with regards to authentication and attribute resolution. 

When authenticating against my test SP, an LDAP lookup is completed with the settings in ldap.properties that I have configured. Of course I do not get any attributes back because I have not configured my resolver, but I at least get a response that this account with password were checked against my AD source and was found to be correct. 

The DataConnector in attribute-resolver.xml seems to want to make another connection to my AD source and pull attributes. While starting up, it wants to at least check and make sure it can authenticate with the source. But it has different requirements for what it is looking for in the connection settings. So I will need to offer it the configuration it expects to connect and pull the attributes. 



Peter Glanville
Enterprise Infrastructure Manager
Office of Information Technology
Marie V. McDemmond Center for Applied Research
555 Park Avenue, Suite 401
Norfolk, Virginia 23504
(757) 823-8098 (Office)
(757) 823-2128 (Fax)
pcglanville at nsu.edu
www.nsu.edu


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Wednesday, April 10, 2019 10:43 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: IdP 3.4.3 attribute-resolver.xml LDAP DataConnector errors

This email may be spoofed.

On 4/10/19, 10:33 AM, "users on behalf of Glanville, Peter C." <users-bounces at shibboleth.net on behalf of pcglanville at nsu.edu> wrote:

> However, when using the dataconnector for the attributes, there are a 
> lot of LDAP variables that don't seem to carry over. For example:

Properties are a syntactic approach with trade offs but the setting that ends up in the XML at the end of the property replacement process is what it is, and it works or not.

Most properties are used because they allow injection of settings into system files that can't be edited, so they get around the limitation. Using them in other cases tends to be a historical choice that was quite often counterproductive as much as useful.
 
> idp.authn.LDAP.useSSL
> idp.authn.LDAP.sslConfig

Neither of those applies to the resolver's configuration syntax to my knowledge. There are no corresponding settings that would use them in a replacement expression in the XML.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net