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(a)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(a)test.com"
}
On vie, jul 13, 2018 at 2:26 , Pedro Igor Silva <psilva(a)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(a)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(a)redhat.com>
> wrote:
>
>
>
> On Tue, Jul 10, 2018 at 6:22 AM, Francisco José Bermejo Herrera <
> francisco.bermejo.herrera(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>