[keycloak-user] Questions about Keycloak UMA 2.0 implementation

[Francisco José Bermejo Herrera]

Thanks for your reply. Yes, that behavior would be perfect.



2018-07-12 15:28 GMT+02:00 Pedro Igor Silva <psilva at 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 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?
>> 
>> 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
>