[keycloak-user] Questions about Keycloak UMA 2.0 implementation
Pedro Igor Silva
psilva at redhat.com
Mon Jul 16 08:55:09 EDT 2018
Cool. Thanks for the feedback.
On Fri, Jul 13, 2018 at 5:51 PM, Francisco José Bermejo Herrera <
francisco.bermejo.herrera at tecsisa.com> wrote:
> 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
>>>>>
>>>>
>>>>
>>>
>>
>
More information about the keycloak-user
mailing list