[keycloak-user] Keycloak availability during LDAP outage

[Hayden Fuss]

Apologies, we were mistaken. We refactored our test script to reuse the
previous set of access/refresh tokens so in the event of Resource Owner
password grants failing, we could keep retrying introspect, userinfo, and
getting a new access token with a refresh token and those endpoints all
work if the LDAP host cannot be resolved or connection is refused.

For anyone interested, here's the script we're using to test OIDC endpoints
as we impact LDAP/MariaDB/ISPN.

On Thu, Aug 16, 2018 at 11:50 AM Hayden Fuss <hfuss at bandwidth.com> wrote:

> Hello,
>
> In testing Keycloak's availability for certain flows/endpoints we noticed
> that introspecting access tokens (never tested refresh tokens) and
> retrieving new access tokens via a refresh token does not work if LDAP is
> down and being used for READ-ONLY user federation. Is this in order to
> guarantee consistency since LDAP is considered the source of truth, and so
> if its down, everything but getting certs is down?
>
> We'd like to prioritize availability over consistency in these scenarios.
> As a result, we were hoping to be able to guarantee tokens could still be
> validated/introspected by Keycloak in an LDAP outage, and new access tokens
> could be granted with a refresh token. That way users/clients could still
> function while their refresh tokens are valid, limiting the severity of an
> LDAP outage.
>
> Are there settings that can be tweaked to enable this? If not, does this
> seem like a reasonable feature request?
>
> On a similar note, can Keycloak adapters verify tokens locally only, and
> then periodically go to Keycloak to verify, rather than verify locally and
> remotely every time?
>
> Best,
> Hayden
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-oidc.py
Type: text/x-python-script
Size: 3687 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20180816/0e13bdc6/attachment.bin