Uploaded image for project: 'Keycloak'
  1. Keycloak
  2. KEYCLOAK-11352

Can't request permissions by name by a non-owner resource service, although the audience is set

    Details

    • Type: Bug
    • Status: Triage (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 4.0.0.Beta1
    • Fix Version/s: None
    • Component/s: Authorization Services
    • Labels:
      None
    • Steps to Reproduce:
      Hide
      • Create resource server CLIENT_A
      • Create resource server CLIENT_B
      • Create RESOURCE_A in CLIENT_B
      • Authenticate using CLIENT_A credentials
      • Make a permission ticket request for RESOURCE_A by it's name and the audience=CLIENT_B
        curl -X POST \
          http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
          -H "Authorization: Bearer ${CLIENT_A_access_token}" \
          --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
          --data "audience=CLIENT_B" \
          --data "permission=RESOURCE_A"
        
      Show
      Create resource server CLIENT_A Create resource server CLIENT_B Create RESOURCE_A in CLIENT_B Authenticate using CLIENT_A credentials Make a permission ticket request for RESOURCE_A by it's name and the audience=CLIENT_B curl -X POST \ http: //${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \ -H "Authorization: Bearer ${CLIENT_A_access_token}" \ --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \ --data "audience=CLIENT_B" \ --data "permission=RESOURCE_A"
    • Docs QE Status:
      NEW
    • QE Status:
      NEW

      Description

      In version 3.4 it was possible to request permissions for resources by a resource server that isn't the owner of the resources, from another resource server, which is the owner of the resources.

      resource server "ClientA" requests a permission ticket from "ClientB" for permissions owned by "ClientB".

      curl -X POST \
        http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
        -H "Authorization: Bearer ${CLIENT_A_access_token}" \
        --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
        --data "audience={CLIENT_B_client_id}" \
        --data "permission=Resource A#Scope A" \
        --data "permission=Resource B#Scope B"
      

      Since version 4, it now results in a not found error:

      {
      error: 'invalid_resource',
      error_description: 'Resource with id [my-resource-name] does not exist.' 
      }
      
      • When a user's token is used, it handles it correctly and finds the resources and permissions by the resource name, regardless of the owner.

      This is because of a potential name conflict between resource servers as Pedro Igor Silva said:

      This is because resources can have the same name but different owners. If the client is not acting on behalf of the user (user is subject in token) it won't be able to send permission requests using the resource name. If the client is acting on behalf of the user, then the server is capable of matching the correct resources.

      But, by also sending the "audience" parameter, it can be used to filter the correct resource server and prevent resource name conflicts and act like a user's request evaluation.

      This is the part of the code that I found that creates the difference between the users and resources servers in the resource permissions evaluation - https://github.com/keycloak/keycloak/blob/9c2525ec1afb6737dd012d3c744a4098b787b3f7/services/src/main/java/org/keycloak/authorization/authorization/AuthorizationTokenService.java#L464

      Hope it's clear enough. Thanks!

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                orharary Or Harary
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: