idp.authn.LDAP.sslConfig set to jvmTrust odity

[Cantor, Scott]

On 5/14/15, 7:08 PM, "Jeffrey Crawford" <jeffreyc at ucsc.edu> wrote:
>
>I'm not quite sure I understand though. I thought setting idp.authn.LDAP.sslConfig = jvmTrust means we don't need to load a trust certificate or keystore file as we a are using the java default trust store. 

It means the properties aren't used, it doesn't mean syntactically things load without them. To do that we would have to provide default values (which would be the same as what's in the file and be non-existent).

Properties are not a panacea, and my general impression is that the ones that point to files don't work all that well because it becomes confusing to make them "optional".

>However If I comment out idp.authn.LDAP.trustCertificates
> the resolver wont start because it's is not set to anything. Should we not need set that attribute if we are using jvmTrust?

It doesn't matter what it's set to but unsetting it just isn't going to work. If you want to change the files so it does work, you can, but that's just extra work at this point.

Of course, it matters very much what it's set to if you use a resolver file that actually references that property, which is what you were (apparently) doing.

>for example I "thought" the following would be a valid config:
>idp.authn.LDAP.sslConfig = jvmTrust
>#idp.authn.LDAP.trustCertificates = /no/file/needed
>#idp.authn.LDAP.trustStore = /no/file/needed

It's not, because there is no default value for those properties. If they're not set, it will blow up. This is just the reality. It doesn't matter whether it's good, bad, right, wrong. That's what it is at the moment.

>I may just be misunderstanding jvmTrust. In essence we want to rely on java's own trust store because we use "real" certificates from Komo and we don't want to have to remember to reset the ldap certificate file when the ldap cert is replaced.

You don't have to. The trust material you put into the file that property is referring to is still the CA/chain, not the server cert, if that's what you want to do. It's a trust store, same as the cacerts file is. You should not use JVM trust in general and you don't gain anything from doing so, regardless of the rest of the issues. It's one-time configuration either way.

-- Scott