IDPv3 Attribute Resolver help
Tim Williams
tmw at autotrain.org
Tue Nov 8 09:04:55 EST 2016
Further to this problem, I've run a few more tests and have still gotten
nowhere.
Firstly, my config has the following in ldap.properties:
idp.authn.LDAP.ldapURL = ldap://<my ad server>:389
idp.authn.LDAP.useStartTLS = false
idp.authn.LDAP.useSSL = false
While the resolver config looks like this:
<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
baseDN="%{idp.attribute.resolver.LDAP.baseDN}"
principal="%{idp.attribute.resolver.LDAP.bindDN}"
principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}">
<dc:FilterTemplate>
<![CDATA[
%{idp.attribute.resolver.LDAP.searchFilter}
]]>
</dc:FilterTemplate>
<dc:StartTLSTrustCredential id="LDAPtoIdPCredential"
xsi:type="sec:X509ResourceBacked">
<sec:Certificate>%{idp.attribute.resolver.LDAP.trustCertificates}</sec:Certificate>
</dc:StartTLSTrustCredential>
</resolver:DataConnector>
This refuses to start telling me that the certificate file can't be
found, even though it shouldn't be used. I have also tried the following:
- Setting useStartTLS="false" rather than taking the parameter passed
through from ldap.properties. This made no difference.
- Removing the <dc:StartTLSTrustCredential> tag on the grounds that it's
not needed. This gave an "Invalid Attribute resolver configuration." error.
- Using just <dc:StartTLSTrustCredential/>. This gave an "Invalid
Attribute resolver configuration." error.
- Creating an empty certificate file and pointing the config at that.
The logic being that the code still tests for the presence of the file
even if it's not needed. This gave an error telling me the cert file was
empty.
So it would seem that the LDAP attribute resolver requires a certificate
regardless of the whether SSL/TLS is turned on elsewhere. Our AD admin
tells me that we don't have TLS configured on our test ADsystem, so I
don't have a certificate to put in here. I'm beginning to think that the
only way to solve this will be either to configure SSL/TLS on the AD
server (which we would prefer to not have to bother with) or patch the
underlying Shibboleth code so that the LDAP attribute resolver obeys the
useStartTLS/useSSL parameters and skips the certificate steps (which I
would already have expected to be the case).
Tim W
--
Tim Williams BSc MSc MBCS
AutoTrain
58 Jacoby Place
Priory Road
Edgbaston
Birmingham
B5 7UW
United Kingdom
Web : http://www.autotrain.org, http://www.utrain.info
Tel : +44 (0)844 487 4117
AutoTrain is a trading name of EuroMotor-AutoTrain LLP
Registered in the United Kingdom, number: OC317070.
More information about the users
mailing list