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(a)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