[keycloak-user] Questions about Keycloak UMA 2.0 implementation
Pedro Igor Silva
psilva at redhat.com
Fri Jul 13 11:57:45 EDT 2018
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