computedid connector ignores leading and trailing white space in salt
Description
Environment
Activity
See http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load%28java.io.Reader%29
Leading whitespace after the = or : delimiter is ignored. It would have to be escaped with a backslash to get it included, something like key = \ value
Another possible workaround would be using the XML property syntax Java supports.
I can't make the property indirection workaround work. I've put the property in attribute-resolver.xml:
salt="%{idp.computed.salt}">
and the salt value in idp.properties as this (which has 7 leading spaces and 8 trailing spaces):
idp.computed.salt= bunnies bouncing in fields of happiness
and also as this:
idp.computed.salt= bunnies bouncing in fields of happiness
to allow for the convention in idp.properties of putting a space before the property value. But neither reproduces the ePTID hash value I get with Rod's fix in place and in v2.
The log doesn't help, as it now doesn't tell me the value of the salt:
2016-05-06 17:41:31,548 - DEBUG [net.shibboleth.idp.attribute.resolver.spring.dc.impl.BaseComputedIDDataConnectorParser:80] - Data Connector 'computedID': Generated Attribute: 'computedID', sourceAttribute = 'uid', salt (or property): '%{idp.computed.salt}'
It does make a difference if I change the number of trailing and/or leading spaces, but I can't seem to home in on getting a combination that gives me the right ePTID value.
Rod has advised me that the salt value should not be enclosed in double-quotes in idp.properties.
Thanks for the test Sara.
Fixed as r8230.
Documentation added to both the release notes.
Workaround noted in the specific documentation
Sara, I assume you noted Rod's point about the property indirection being a workaround? That's probably the best choice for now, assuming this doesn't impact all that many people, in which case we should get that into the documentation until 3.3 fixes it.
OK, having put it in edit-webapp/WEB-INF/lib and rebuilt the war and restarted jetty I can now answer my own question.
It worked. Hurrah! And many thanks.
The computedid connector throws away any and all leading and/or trailing space characters in the salt value and calculates the hash as if they were not there. This can be seen in the IdP log. Reproduced in 3.2.1 and 3.1.1.
For example, a log extract from 3.1.1:
2016-05-03 15:53:10,852 - DEBUG [net.shibboleth.idp.attribute.resolver.spring.dc.BaseComputedIDDataConnectorParser:83] - Data Connector 'computedID': generated Attribute : 'computedID', sourceAttribute = 'uid', salt: '[98, 117, 110, 110, 105, 101, 115, 32, 98, 111, 117, 110, 99, 105, 110, 103, 32, 105, 110, 32, 102, 105, 101, 108, 100, 115, 32, 111, 102, 32, 104, 97, 112, 112, 105, 110, 101, 115, 115]'.
But the value of the salt in attribute-resolver.xml is this:
salt=" bunnies bouncing in fields of happiness ">
This is different behaviour from v2.x, which makes it impossible as it stands for the same hash values to be maintained over a migration to v3.x if an affected salt value has been used.