Thanks for your reply. Yes, that behavior would be perfect.
2018-07-12 15:28 GMT+02:00 Pedro Igor Silva <psilva(a)redhat.com>:
Hi,
Currently, we just set upgraded == true if an rpt was provided. I
think we can change the behavior to:
* Set upgraded == false if any permission granted by the RPT was
denied
* DENY request if ALL permissions from ticket were denied (and avoid
issuing a new rpt == previous rpt)
Wdyt ?
On Tue, Jul 10, 2018 at 6:22 AM, Francisco José Bermejo Herrera
<francisco.bermejo.herrera(a)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.sectio...
> :
>
> > 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!
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user