v2->v3 upgrade, properties files

[Baron Fujimoto]

On Wed, Jun 22, 2016 at 09:19:24PM +0000, Cantor, Scott wrote:
>> This was carried over from or v2 config where we have:
>> ===== attribute-resolver.xml =====
>> 
>>     <resolver:DataConnector xsi:type="dc:LDAPDirectory"
>>             id                  = "UH_LDAP"
>>             useStartTLS         = "${ldap.useStartTLS}"
>
>I think we did *not* carry over that Filter feature. We know people used it, but it wasn't practical to do that, we changed the resource loading code entirely to make it more Spring-based. But the Spring property replacement should be mostly usable in its place, you'll have to change the syntax though.
>
>I will update the docs, I don't think I noted that missing feature.
>
>> However, in v3, it looks like these properties now reside in ldap.properties
>> with entries like:
>
>Properties are arbitrary and the use of them in the resolver is optional, and there is no requirement around what file they live in.
>
>> But the ldap.properties file doesn't seem to actually be referenced by
>> attribute-resolver.xml. I apologize if this is a dumb question, but how do
>> you do the equivalent of what was done in our v2 services.xml to get the
>> v3 attribute-resolver to read properties from ldap.properties?
>
>idp.properties is the bootstrapping file, and it points to any other property files you want to load, and all of them are loaded globally into Spring and usable in any Spring file. We made it possible to use properties in some/most of the legacy schemas, but you have to use %{} as delimiters.
>
>> The LDAPConnector page mentions the springResource or
>> springResourceRef attributes delegating the configuration is delegated to the supplied
>> resources, but if this the right track, I'm still not quite closing the gap.
>
>You don't have to do that to use properties. That's for using Spring syntax instead of the custom schema.

Ok, thanks for the info. Just to make sure I understand correctly, are
properties globally accessible as long as they are defined in
idp.properties or one of the additional files defined by
idp.additionalProperties?

This seems consistent with what I guessed might be happening, but given
this, I'm still confused by the error we see:

net.shibboleth.utilities.java.support.service.ServiceException: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 583 in XML document from file [/home/shib/idp/conf/attribute-resolver.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 583; columnNumber: 87; cvc-enumeration-valid: Value '%{idp.attribute.resolver.LDAP.connectionStrategy}' is not facet-valid with respect to enumeration '[DEFAULT, ACTIVE_PASSIVE, ROUND_ROBIN, RANDOM]'. It must be a value from the enumeration.

Relevant configs, based on previous discussion.

===== idp.properties =====
idp.additionalProperties= /conf/ldap.properties, /conf/saml-nameid.properties, /conf/services.properties
=====

===== ldap.properties =====
idp.attribute.resolver.LDAP.ldapURL             = ldaps://ldap.example.edu
idp.attribute.resolver.LDAP.baseDN              = dc=example, dc=edu
idp.attribute.resolver.LDAP.bindDN              = cn=shib-idp, dc=example, dc=edu
idp.attribute.resolver.LDAP.bindDNCredential    = ***********
idp.attribute.resolver.LDAP.useStartTLS         = false
idp.attribute.resolver.LDAP.connectionStrategy  = DEFAULT
=====

===== attribute-resolver.xml =====
    <resolver:DataConnector xsi:type="dc:LDAPDirectory"
            id                  = "UH_LDAP"
            useStartTLS         = "%{idp.attribute.resolver.LDAP.useStartTLS}"
            ldapURL             = "%{idp.attribute.resolver.LDAP.ldapURL}"
            baseDN              = "%{idp.attribute.resolver.LDAP.baseDN}"
            principal           = "%{idp.attribute.resolver.LDAP.bindDN}"
            principalCredential = "%{idp.attribute.resolver.LDAP.bindDNCredential}"
            connectionStrategy  = "%{idp.attribute.resolver.LDAP.connectionStrategy}">
=====

So it doesn't complain about the other LDAP properties, but just
connectionStrategy?

I don't know if it's relevant, but our idp.home isn't /opt/shibboleth-idp
but I do have it defined as a JAVA_OPT when starting the IdP.

>> I'm also not finding a good reference on the use of "%" vs "$" for
>> interpolating the placeholder values. I've tried both $ and % in
>> attribute-resolvers.xml with the same results. The use of ":value"
>> also suggests conditional interpolation?
>
>Velocity uses $ so we had to override Spring's defaults to switch it to %. In all other ways they're just Spring property replacement, documented by Spring. %{property:value} means value is a default used if property isn't set. There's not really a conditional feature but there are some fancy things that are possible.
>

Ok, thanks again, that pointed me to another useful reference at
<https://wiki.shibboleth.net/confluence/display/IDP30/SpringConfiguration>

>All that said...not everything can be done with properties, and anything that's defined in the schema as something other than xs:string is something that either for technical reasons or because of simple oversight isn't usable that way. The schema doesn't know about properties and validation happens before replacement, so if it's an enum, it can't be set with a property. If that was possible in V2, that means the filtering interface must have done the replacement before the data hit the XML parser. I don't know the mechanics of it.

-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum