If truststore provider is configured, and enabled, then SSLSocketFactory will use our custom truststore. If truststore provider is not configured it will use the java default SSLSocketFactory.
So without configuring truststore provider in keycloak-server.json the -Djavax.net.ssl.trustStore will be honored.
On Fri, Feb 19, 2016 at 1:12 PM, Marek Posolda <mposolda@redhat.com> wrote:
On 19/02/16 09:42, Marko Strukelj wrote:
If it's on by default, will it work with the default java implementation and with "javax.net.ssl.trustStore" property? I am thinking about backwards compatibility. If someone used older Keycloak version and he set his truststore for LDAP by system property "I was thinking something like truststore use be 'on' by default. Then checking URL - if it starts with ldaps:// it means truststore SSLSocketFactory should be set.
But not sure if that's really correct - maybe there are some other LDAP providers that are activated by some other url scheme, not 'ldap:' / 'ldaps:'.The switch you suggest could then be there so that truststore use can be turned off if someone wants to delegate it to default java implementation.
javax.net.ssl.trustStore", then after Keycloak upgrade, the things won't work for him (unless he edits keycloak-server.json and configured truststore SPI). Is it correct assumption?
Then maybe it should be "on" by default, but LDAP providers migrated from previous version will still have it off? Or we can just put the note do migration guide.
Marek
On Fri, Feb 19, 2016 at 8:48 AM, Marek Posolda <mposolda@redhat.com> wrote:
On 18/02/16 22:40, Marko Strukelj wrote:
Yeah. I am thinking about something simple like just add on/off flag "Use Truststore SPI" to the LDAP provider configuration. When on, it will use the snippet you added to set "org.keycloak.connections.truststore.SSLSocketFactory" .I saw it set during my manual LDAP connectivity tests, that's why I added this "ssl".equals(protocol) check. But maybe it would be more appropriate to solve truststore activation in some other way?
That property "securityProtocol" is just the leftover from Picketlink, which wasn't never used in practice. Even Picketlink didn't use it AFAIR. It's fine to be removed.
Marek
On Thu, Feb 18, 2016 at 10:17 PM, Marek Posolda <mposolda@redhat.com> wrote:Ah, but we're not set securityProtocol anywhere in the LDAP provider admin console ATM, so it can't work now. I will take a look for 1.9 and retest with Active Directory. Thanks Marko for pointing this. Marek On 18/02/16 19:12, Marko Strukelj wrote:LDAP store needs to have configuration property 'securityProtocol' set to 'ssl' for truststore to be used. See: https://github.com/keycloak/keycloak/blob/1.9.0.CR1/federation/ldap/src/main/java/org/keycloak/federation/ldap/idm/store/ldap/LDAPOperationManager.java#L488 On Thu, Feb 18, 2016 at 5:20 PM, Jason Axley <jaxley@expedia.com> wrote:Will do. This is Active Directory. -Jason From: Marek Posolda <mposolda@redhat.com> Date: Thursday, February 18, 2016 at 8:15 AM To: Jason Axley <jaxley@expedia.com>, "keycloak-user@lists.jboss.org" <keycloak-user@lists.jboss.org> Subject: Re: [keycloak-user] LDAPS configuration fails "Test authentication" That's possible. Could you please create JIRA for this? Which LDAP server are you using btv? Not sure if it's related, but maybe yes... Thanks, Marek On 18/02/16 17:04, Jason Axley wrote: I got the keystore working in the keycloak-server.json config to enable SMTP TLS connections to Amazon SES so I know that is being picked up: "truststore": { "file": { "file": "${jboss.server.config.dir}/keycloak.jks", "password": “password", "hostname-verification-policy": "WILDCARD", "disabled": false } } But, this same configuration is not applied to the LDAP connections. I finally got it to work by adding the Java keystore arguments to the startup: nohup ../bin/standalone.sh -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks -Djavax.net.ssl.trustStorePassword=password Would seem to be a bug to not apply the same keystore configuration to the LDAP connections? -Jason From: Marek Posolda <mposolda@redhat.com> Date: Wednesday, February 17, 2016 at 11:10 PM To: Jason Axley <jaxley@expedia.com>, "keycloak-user@lists.jboss.org" <keycloak-user@lists.jboss.org> Subject: Re: [keycloak-user] LDAPS configuration fails "Test authentication" On 17/02/16 22:46, Jason Axley wrote: I followed some documentation like https://developer.jboss.org/wiki/LDAPSecurityRealmExamples for configuring JBOSS to use LDAP over SSL to Active Directory but can’t seem to get Keycloak to honor the trust settings in the configured keystore. 2016-02-17 21:33:49,670 ERROR [org.keycloak.services.managers.LDAPConnectionTestManager] (default task-2) Error when authenticating to LDAP: simple bind failed: server.example.com:636: javax.naming.CommunicationException: simple bind failed: server.example.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target] at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219) This is the configuration I’m using for the standalone server: <security-realm name="LdapSSLRealm"> <authentication> <truststore path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=“password" /> </authentication> </security-realm> </security-realms> <outbound-connections> <ldap name=“AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm" /> </outbound-connections> I have all of the certs in the chain imported into the keystore: keytool -list -keystore ../configuration/keycloak.jks Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 5 entries cert1, Feb 17, 2016, trustedCertEntry, Certificate fingerprint (SHA1): D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE rootcert2, Feb 17, 2016, trustedCertEntry, Certificate fingerprint (SHA1): 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A mykey, Feb 12, 2016, trustedCertEntry, Certificate fingerprint (SHA1): 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15 rootcert, Feb 17, 2016, trustedCertEntry, Certificate fingerprint (SHA1): 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD intermediateu, Feb 17, 2016, trustedCertEntry, Certificate fingerprint (SHA1): E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D Is there a way to find out if Keycloak/jboss is picking up this truststore config? Seems that it’s not. Any other ideas? Yes, it seems that it's not picking it. AFAIK we don't support retrieve truststore from the wildfly configuration of security-realm in standalone.xml . Maybe we should... At this moment, what should work to configure truststore is either: - Configure truststore SPI in keycloak-server.json. See http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231 - add system properties javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword Marek -Jason _______________________________________________ keycloak-user mailing list keycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user