[keycloak-user] Questions about Keycloak UMA 2.0 implementation

[Francisco José Bermejo Herrera]

Hello, we are testing Keycloak 4.1.0.Final for authentication and
authorization (UMA 2.0 flow).

Some assumptions:

   - The Resource Server owns the resource Foo, and protects it by using
   two scope-based permissions, one requiring READ scope, and the other one
   requiring WRITE scope.
   - User Alice has been granted READ scope for resource Foo.
   - We are not using Policy Enforcers. Enforcement will be implemented at
   the Resource Server.

We are modeling the following flow:

   1. The Requesting Party (Alice) requests access to resource Foo in the
   Resource Server. This request DOES NOT provide an RPT.
   2. The Resource Server detects the absence of RPT, so it requests a
   Permission Ticket to Keycloak, for the Foo resource and both READ and WRITE
   scopes (providing a valid PAT).
   3. Keycloak returns a valid Permission Ticket to the Resource Server.
   4. The Resource Server returns the Permission Ticket (including Keycloak
   token URI (http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token)
   at WWW-Authorization header) with status code 401 to the Requesting Party.
   5. The Requesting Party sends the Permission Ticket (for the Foo
   resource and both READ and WRITE scopes) to Keycloak, in order to get a
   valid RPT.

Here is where things start to get confusing. We expected that Keycloak
would reject the authorization request due to failed permission evaluation
(Alice has READ scope for resource Foo, but DOES NOT have WRITE scope).
Nevertheless, Keycloak returns a valid RPT, granting permission for
resource Foo (just for READ scope).

We are aware that this behavior is UMA 2.0 compliant
<https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#rfc.section.3.6.4>
:

> If the value is non-null and CandidateGrantedScopes < RequestedScopes, the
> authorization server MUST subsequently issue either an RPT containing
> CandidateGrantedScopes (upgrading as appropriate; see below), or one of the
> error codes. The reason for the two options is that granting only partial
> scopes may not be useful for the client's and requesting party's purposes
> in seeking authorization for access.


But as the RFC explicitly points out, this behavior may not be useful for
the client. We think that the RFC is right, because this renders the client
unable to tell whether the authorization has been partially or completely
fulfilled. And consequently the Resource Server will request again a
Permission Ticket for the Foo resource and both READ and WRITE scopes, so
the whole flow will be repeated over and over again. If this is Keycloak
expected behavior, how can we avoid the infinite loops?

Another question is, when providing a valid RPT along with a Permission
Ticket, why Keycloak deems an RPT as upgraded = true even when the
requested resource has not been authorized? It returns the same RPT with
just jti, exp and iat updated. Since we think that the Authorization Server
must be the one stopping the UMA flow, should not Keycloak return a 403
Forbidden instead? Is this behavior configurable in any way?

Thank you in advance!