[keycloak-user] Questions about Keycloak UMA 2.0 implementation

[Pedro Igor Silva]

On Tue, Jul 10, 2018 at 6:22 AM, Francisco José Bermejo Herrera <
francisco.bermejo.herrera at tecsisa.com> wrote:

> 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?
>

For this particular case, each scope is associated with a specific HTTP
method ? Can't you obtain tickets accordingly including only the scopes you
need ?

As you noticed, by default, Keycloak issues a RPT for any resource/scope
you sent along with an authorization request. Resource servers (or clients
sending authz requests directly without ticket) should be able to ask only
for specific resources/scopes.


>
> 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!
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>