[keycloak-user] Keycloak 4
Pedro Igor Silva
psilva at redhat.com
Thu Jun 28 09:03:41 EDT 2018
On Wed, Jun 27, 2018 at 2:25 PM, Corentin Dupont <corentin.dupont at gmail.com>
wrote:
>
>
> On Wed, Jun 27, 2018 at 6:01 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>>
>>
>> On Wed, Jun 27, 2018 at 12:21 PM, Corentin Dupont <
>> corentin.dupont at gmail.com> wrote:
>>
>>> That's great, I was able to "share" a resource in my account console.
>>> As a keycloak admin, where to see all the sharings performed by users?
>>>
>>
>> We don't have this in admin console. The user-managed policies are hidden
>> in the admin console, the reason being to avoid admins changing them
>> without user consent. This was a tuff decision and I'm open to discuss
>> different ideas if you think differently.
>>
>
> Yeah it's arguable :) Keycloak Admin can "impersonate" a user so I'd say
> they already have access to that user sharings?
> Furthermore, it hides a bit the information, making this feature less
> discoverable. Putting all the sharings in one place might make things more
> clear.
>
Admins still have access to these sharings via API. But yeah, they are
hidden from Admin Console.
>
>
>>
>>
>>>
>>> Also, how to take into account this sharing in permission evaluation?
>>> Should I write specific policies to take into resource sharing?
>>> For instance, I have a javascript policy to authorize the resource owner
>>> to access his resource.
>>> Should I write a "is shared with you" policy?
>>>
>>
>> If you do that, you are just defining a regular policy it will not be
>> enough to let the user manage permissions via My Resources. This is how you
>> could achieve the "sharing" functionality before the latest changes to UMA.
>>
>> However, we have also introduced a Policy API to the Protection API. From
>> this API you are able to create additional "user-managed" permissions and
>> still have your users able to manage them via My Resources. Documentation
>> is also updated in upstream/master.
>>
>> This API basically allows you to define additional permissions to a
>> user's resource such as using roles, groups, clients or even conditions
>> using JS.
>>
>
> Some questions:
> - A resource owner doesn't necessarily have permission to all the scopes
> on his own resource, it still depends on the policies, right?
> For instance, a resource owner could "view" his resource, but not "delete"
> it.
>
Yes, the behavior is the same as before. Evaluation of permissions for a
resource will consider any policy gorverning access to resources regardless
if the requester is the owner or not.
>
> - when a resource is shared by the owner with another user, he can share
> any scope, right? Regardless if he effectively have permission on that
> scope.
> When the recipient will make a permission request, Keycloak will first
> check that the original owner have permission.
> The permission is granted by transitivity, at run time.
> So, as a owner I can share a resource with a user with the "delete" scope,
> but the recipient user might not effectively obtain permission when
> requesting, if I don't actually have permission.
>
I see your point. But as it stands today, owners can grant any scope
(regardless if they have permissions or not) associated with a resource.
Are suggesting to hide the scopes the owner is not granted so they can not
grant these scopes to others ?
>
> - Is there a way to control which resources/scopes can be shared?
> For example, I'm OK if a resource owner can delete his own resource, but I
> don't want that he could transmit that privilege to another user.
>
There isn't. What we support is a enable/disable swtich on the resource
that tells if a resource should allow user-managed access. There is nothing
like that to scopes ....
Not sure if this wtich switch on resources is what you are asking. So, for
scopes we would need something similar ...
>
> - silly question, can you share a shared resource? What about ownership
> transfer?
>
Nope. I would suggest to not support that until we have more people asking
and string requirements that justify such thing.
Tks.
>
> Cheers
> Corentin
>
>
>
>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 27, 2018 at 3:36 PM, Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>>
>>>> Think we are missing this in docs :)
>>>>
>>>> You need to enable "User-Managed Access" in Realm Settings (General
>>>> tab).
>>>>
>>>> On Wed, Jun 27, 2018 at 6:20 AM, Corentin Dupont <
>>>> corentin.dupont at gmail.com> wrote:
>>>>
>>>>> OK, interesting: I didn't know about this console :)
>>>>> I can access it with my "test" user, but I don't see the "My
>>>>> Resources" menu entry (see screenshot).
>>>>> I created some resources owned by that user (using the API). But they
>>>>> don't show up.
>>>>> What did I missed?
>>>>>
>>>>> On Tue, Jun 26, 2018 at 2:42 PM, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Yeah, you can access those claims in a JS policy.
>>>>>>
>>>>>> Regarding the "account management console" take a look here:
>>>>>> https://www.keycloak.org/docs/latest/authorization_ser
>>>>>> vices/index.html#_service_authorization_api_aapi.
>>>>>>
>>>>>> On Mon, Jun 25, 2018 at 1:28 PM, Corentin Dupont <
>>>>>> corentin.dupont at gmail.com> wrote:
>>>>>>
>>>>>>> Ok, I see the "claim_token" parameter in the request.
>>>>>>> I guess you can retrieve those claims in a javascript rule, from the
>>>>>>> evaluation context.
>>>>>>>
>>>>>>> By the way, I still cannot figure out where is the "account
>>>>>>> management console", where user can manager users access (as per the
>>>>>>> release notes)??
>>>>>>>
>>>>>>> On Fri, Jun 22, 2018 at 7:09 PM, Pedro Igor Silva <psilva at redhat.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> The new form of obtaining entitlements relies solely on the token
>>>>>>>> endpoint just like when you are obtaining access tokens using other OAuth2
>>>>>>>> grant types. With that in mind the new format of the request should be a
>>>>>>>> HTTP POST + parameters. Check this documentation [1] for more details.
>>>>>>>>
>>>>>>>> Regarding pushing claims to your policies, there is a specific HTTP
>>>>>>>> parameter that you can use to pass a Base64 encoded JSON with the claims
>>>>>>>> you want to push.
>>>>>>>>
>>>>>>>> [1] https://www.keycloak.org/docs/latest/authorization_servi
>>>>>>>> ces/index.html#_service_obtaining_permissions
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jun 22, 2018 at 12:09 PM, Corentin Dupont <
>>>>>>>> corentin.dupont at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Thanks Pedro, I went through the pull request.
>>>>>>>>> I'm not sure how to modify my entitlement requests?
>>>>>>>>> For example I have:
>>>>>>>>> curl -X POST -H "Content-Type: application/json" -H
>>>>>>>>> "Authorization: Bearer $TOKEN" -d '{
>>>>>>>>> "permissions" : [
>>>>>>>>> {
>>>>>>>>> "resource_set_name" : "Sensors",
>>>>>>>>> "scopes" : [
>>>>>>>>> "sensors:update"
>>>>>>>>> ]
>>>>>>>>> }
>>>>>>>>> ]
>>>>>>>>> }' "http://localhost:8080/auth/realms/waziup/authz/entitlement/
>>>>>>>>> waziup"
>>>>>>>>>
>>>>>>>>> This call has been moved to uma-2, right?
>>>>>>>>> Can I add pushed claims to this call? What I'm imagining is:
>>>>>>>>>
>>>>>>>>> curl -X POST -H "Content-Type: application/json" -H
>>>>>>>>> "Authorization: Bearer $TOKEN" -d '{
>>>>>>>>> "permissions" : [
>>>>>>>>> {
>>>>>>>>> "resource_set_name" : "Sensors",
>>>>>>>>> "scopes" : [
>>>>>>>>> "sensors:update"
>>>>>>>>> ]
>>>>>>>>> }
>>>>>>>>> ],
>>>>>>>>> claims: ["owner": "cdupont"]
>>>>>>>>> }' "http://localhost:8080/auth/realms/waziup/authz/entitlement/
>>>>>>>>> waziup"
>>>>>>>>>
>>>>>>>>> In this example, I would like to push the owner of the sensor
>>>>>>>>> ("cdupont"), which I take from our own database before calling the API.
>>>>>>>>>
>>>>>>>>> Sorry about the questions, maybe I should just wait that the
>>>>>>>>> documentation is merged :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jun 22, 2018 at 4:37 PM, Pedro Igor Silva <
>>>>>>>>> psilva at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> We have a few changes to docs that were not released because the
>>>>>>>>>> PR [1] was not merged on time. But you can check about pushed claims (if
>>>>>>>>>> you are using our adapters) here [2].
>>>>>>>>>>
>>>>>>>>>> Regards.
>>>>>>>>>> Pedro igor
>>>>>>>>>>
>>>>>>>>>> [1] https://github.com/keycloak/keycloak-documentation/pull/402
>>>>>>>>>> [2] https://www.keycloak.org/docs/latest/authorization_servi
>>>>>>>>>> ces/index.html#_enforcer_claim_information_point
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 20, 2018 at 10:04 AM, Corentin Dupont <
>>>>>>>>>> corentin.dupont at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi guys,
>>>>>>>>>>> I'm playing with the new version of Keycloak (
>>>>>>>>>>> https://www.keycloak.org/docs/latest/release_notes/index.html)
>>>>>>>>>>>
>>>>>>>>>>> I have some questions:
>>>>>>>>>>> - where is the "account management console"?
>>>>>>>>>>> - How to use pushed claims? Which APIs are affected?
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>> Corentin
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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