[keycloak-user] Questions about Keycloak UMA 2.0 implementation

Fri Jul 13 16:51:24 EDT 2018

I see. There is no problem either way. BTW, we tested your implementation
of the proposed changes and it seems to work perfectly. Nice job!

2018-07-13 17:57 GMT+02:00 Pedro Igor Silva <psilva at redhat.com>:

> Yeah, you are right. Bad example. I was thinking about asking two scopes
> and returning only one of them because other was denied ...
>
>
> On Fri, Jul 13, 2018 at 9:47 AM, Francisco José Bermejo Herrera <
> francisco.bermejo.herrera at tecsisa.com> wrote:
>
>> We're OK with all your changes. But, just a quick remark, you say:
>>
>> Still keep current behavior where the server may grant additional
>> permissions even though you requested only a sub set of them. E.g.: You ask
>> for source "foo" + scope "a" and the server may grant resource "foo" +
>> scope "a" and "b".
>>
>>
>> IMHO this isn't the current behavior, since if you ask for resource "foo"
>> + scope "a", the server grants "foo" + scope "a". But, it is true that if
>> you ask for resource "foo" + any scope (by leaving scope empty), the server
>> may grant you resource "foo" + scope "a" and "b".
>>
>> For example:
>>
>> - Ticket request (just "read" scope)
>>
>> POST /auth/realms/TestRealm/authz/protection/permission HTTP/1.1
>>
>> Host: 127.0.0.1:8080
>> Content-Type: application/json
>> Authorization: Bearer eyJ...
>> [
>> {"resource_id": "fooresources", "resource_scopes": ["read"]}
>> ]
>>
>>
>> - RPT issued using the ticket (note: Alice has permissions for both
>> "read" and "write" scopes)
>>
>> {
>>
>>   "jti": "2a8a98ed-f058-4d4d-8321-1501896f773d",
>>
>>   "exp": 1531489206,
>>
>>   "nbf": 0,
>>
>>   "iat": 1531485606,
>>
>>   "iss": "http://127.0.0.1:8080/auth/realms/TestRealm",
>>
>>   "aud": "auth-demo-ws",
>>
>>   "sub": "4c3b0694-c1fe-405a-ac35-d4cf9e14aabd",
>>
>>   "typ": "Bearer",
>>
>>   "azp": "auth-demo-webapp",
>>
>>   "auth_time": 0,
>>
>>   "session_state": "34a4ec1e-9bd3-4413-b785-ae0dda7287d6",
>>
>>   "acr": "1",
>>
>>   "allowed-origins": [],
>>
>>   "realm_access": {
>>
>>     "roles": [
>>
>>       "offline_access",
>>
>>       "uma_authorization"
>>
>>     ]
>>
>>   },
>>
>>   "resource_access": {
>>
>>     "auth-demo-webapp": {
>>
>>       "roles": [
>>
>>         "owner"
>>
>>       ]
>>
>>     },
>>
>>     "auth-demo-ws": {
>>
>>       "roles": [
>>
>>         "fooresource-reader",
>>
>>         "fooresource-writer"
>>
>>       ]
>>
>>     }
>>
>>   },
>>
>>   "authorization": {
>>
>>     "permissions": [
>>
>>       {
>>
>>         "scopes": [
>>
>>           "read"
>>
>>         ],
>>
>>         "rsid": "dbc5e6a1-d65a-4510-b354-d12b8dd67dc2",
>>
>>         "rsname": "fooresources"
>>
>>       }
>>
>>     ]
>>
>>   },
>>
>>   "scope": "email profile",
>>
>>   "tenant_id": "12345",
>>
>>   "email_verified": true,
>>
>>   "roles": [
>>
>>     "role_owner"
>>
>>   ],
>>
>>   "name": "Alice Brown",
>>
>>   "groups": [
>>
>>     "/auth-demo/admin"
>>
>>   ],
>>
>>   "preferred_username": "alice",
>>
>>   "given_name": "Alice",
>>
>>   "family_name": "Brown",
>>
>>   "email": "alice at test.com"
>>
>> }
>>
>>
>> On vie, jul 13, 2018 at 2:26 , Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>
>> I see. Just to make sure we are aligned. The changes I'm proposing are
>> more aligned with spec and provide:
>>
>> * Only mark RPT as upgraded if ALL permissions granted by a previous RPT
>> were granted
>> * DENY authorization requests in case you are sending a previous issued
>> RPT and ANY additional permissions in a ticket are DENIED.
>> * Still keep current behavior where the server may grant additional
>> permissions even though you requested only a sub set of them. E.g.: You ask
>> for source "foo" + scope "a" and the server may grant resource "foo" +
>> scope "a" and "b".
>>
>> On Fri, Jul 13, 2018 at 5:17 AM, Francisco José Bermejo Herrera <
>> francisco.bermejo.herrera at tecsisa.com> wrote:
>>
>>> If Keycloak behavior is changed according to your proposal described in
>>> your previous message, then there shouldn't be any problem with authz
>>> requests in our model.
>>>
>>> It is true that the scopes described in our example are a bit
>>> misleading. Think about something like READ and READ-PREMIUM instead, used
>>> at a GET endpoint, and the Resource Server just checks whether one of these
>>> scopes is contained in the RPT, returning a ticket with READ and
>>> READ-PREMIUM when none of them has been provided. When the Client requests
>>> the new RPT by using the ticket, Keycloak would return a RPT including
>>> either READ or READ-PREMIUM, or 403 Forbidden.
>>>
>>> As I said before, this is perfectly aligned with the new Keycloak
>>> behavior.
>>>
>>> On jue, jul 12, 2018 at 7:35 , Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>>
>>>
>>>
>>> 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/r
>>>> ealms/${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.h
>>>> tml#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
>>>>
>>>
>>>
>>
>