[keycloak-user] LDAPS configuration fails "Test authentication"
Marek Posolda
mposolda at redhat.com
Fri Feb 19 08:21:40 EST 2016
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
> <mailto: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 <mailto: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> <mailto: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> <mailto:jaxley at expedia.com> wrote:
>>>>>> Will do.
>>>>>>
>>>>>> This is Active Directory.
>>>>>>
>>>>>> -Jason
>>>>>>
>>>>>> From: Marek Posolda<mposolda at redhat.com> <mailto:mposolda at redhat.com>
>>>>>> Date: Thursday, February 18, 2016 at 8:15 AM
>>>>>>
>>>>>> To: Jason Axley<jaxley at expedia.com> <mailto:jaxley at expedia.com>,"keycloak-user at lists.jboss.org"
>>>>>> <mailto:keycloak-user at lists.jboss.org>
>>>>>> <keycloak-user at lists.jboss.org>
>>>>>> <mailto: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> <mailto:mposolda at redhat.com>
>>>>>> Date: Wednesday, February 17, 2016 at 11:10 PM
>>>>>> To: Jason Axley<jaxley at expedia.com> <mailto:jaxley at expedia.com>,"keycloak-user at lists.jboss.org"
>>>>>> <mailto:keycloak-user at lists.jboss.org>
>>>>>> <keycloak-user at lists.jboss.org>
>>>>>> <mailto: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 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 <http://server.example.com:636>: javax.naming.CommunicationException: simple bind
>>>>>> failed:server.example.com:636 <http://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
>>>>>> <mailto:keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org
>>>>>> <mailto:keycloak-user at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/a3f025c8/attachment.html
More information about the keycloak-user
mailing list