[keycloak-user] LDAPS configuration fails "Test authentication"

Marko Strukelj mstrukel at redhat.com
Fri Feb 19 08:27:57 EST 2016 

I think so, yes.

On Fri, Feb 19, 2016 at 2:21 PM, Marek Posolda <mposolda at redhat.com> wrote:

> Thanks Marko. So we don't need to care about migration then, but put it
> "on" even for migrated from previous version.
>
> Marek
>
>
> On 19/02/16 14:06, Marko Strukelj wrote:
>
> 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.
>
>
> https://github.com/keycloak/keycloak/blob/1.9.0.CR1/services/src/main/java/org/keycloak/truststore/SSLSocketFactory.java#L49
>
> 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 at redhat.com>
> wrote:
>
>> On 19/02/16 09:42, Marko Strukelj wrote:
>>
>> 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.
>>
>> 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 "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 at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> On 18/02/16 22:40, Marko Strukelj wrote:
>>>
>>> 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?
>>>
>>> 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" .
>>>
>>> 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 at redhat.com> <mposolda at 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 at expedia.com> <jaxley at expedia.com> wrote:
>>>
>>> Will do.
>>>
>>> This is Active Directory.
>>>
>>> -Jason
>>>
>>> From: Marek Posolda <mposolda at redhat.com> <mposolda at redhat.com>
>>> Date: Thursday, February 18, 2016 at 8:15 AM
>>>
>>> To: Jason Axley <jaxley at expedia.com> <jaxley at expedia.com>, "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org><keycloak-user at lists.jboss.org> <keycloak-user at 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 at redhat.com> <mposolda at redhat.com>
>>> Date: Wednesday, February 17, 2016 at 11:10 PM
>>> To: Jason Axley <jaxley at expedia.com> <jaxley at expedia.com>, "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org><keycloak-user at lists.jboss.org> <keycloak-user at 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 likehttps://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 at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/83fe3542/attachment-0001.html

More information about the keycloak-user mailing list