Preface

This topic has already been discussed in keycloak-dev mailing list's thread.

By following the updated keycloak's contribution guide, I've post this topic here.

Also, as the keycloak's contribution guide described, more low-level implementation discussions continue in the keycloak-dev mailing list's thread.

Discussion point

Basically, keycloak executes logics on a request from a client by following its client settings(metadata).
E.g., authorization request on authorization Endpoint, token request on token endpoint.

Current client policies' built-in executors cannot override such logics.

Proposal

Revising client policies to override logics based on client settings when keycloak receives a request from a client.
Considering the nature of client "policies", it is better to precede client setting based logics.

Motivation

• Security
  It can enforce logics satisfying some security level regardless of client settings.

• Flexibility
  It can change such enforcing logics dynamically per request from a client

Use Case

• Apply different FAPI security profile per request from the same client dynamically

FAPI 1.0 Baseline security profiles are applied on some requests from a client while FAPI 1.0 Advanced security profile are applied on others from the same client.

The existing client policies can support this use case. However, there is the case that some request obeying FAPI 1.0 Baseline is not accepted.

Notes

This discussion point has been treated in FAPI-SIG. Its detail can be found in the FAPI-SIG's discussion document.