I see ... Does your client know the name of the resource representing the
"/cars/myCar" URI ?
If so, I think you don't even need to design an API for that. But just send
from your client an entitlement request passing the resource/scopes you
want to check for access.
On Fri, Mar 9, 2018 at 9:11 AM, Corentin Dupont <corentin.dupont(a)gmail.com>
wrote:
On Fri, Mar 9, 2018 at 12:53 PM, Pedro Igor Silva <psilva(a)redhat.com>
wrote:
>
>
> On Fri, Mar 9, 2018 at 6:47 AM, Corentin Dupont <
> corentin.dupont(a)gmail.com> wrote:
>
>> Based on my current API, I can see two strategies for displaying the
>> "delete" (or request access) button.
>>
>> I have an API like this:
>>
>> GET /cars
>> POST /cars
>> GET /cars/<carID>
>> DELETE /cars/<carID>
>>
>> When I receive a request, I call keycloak to get authorization on the
>> resource/scope.
>> I also create/delete resources in Keycloak for the POST/DELETE requests.
>>
>> Regarding the display of the "delete" button on the UI, what should I
do?
>> I see two options:
>> 1. Add a "dry_run" query parameter on the DELETE endpoint:
>>
>> DELETE /cars/myCar?dry_run=true
>>
>> This would query only keycloak, and return the status code (200 or 403).
>> Based on that I can display my button or not.
>>
>
> You can send a entitlement request to Keycloak asking permissions for the
> resource. 200/403 will be returned accordingly.
>
Exactly. But my question was more on how to design an API using this
feature :)
>
>
>>
>> 2. Create a specific endpoint for viewing authorizations:
>>
>> GET /permissions
>> {
>> cars=[{myCar: ["view", "delete"]}, {anotherCar:
["view"]}]
>> }
>>
>> What do you think?
>>
>>
>>
>>
>>
>>
>> On Wed, Mar 7, 2018 at 12:31 PM, Pedro Igor Silva <psilva(a)redhat.com>
>> wrote:
>>
>>> I think this is the best way to go ....
>>>
>>> In fact, this is exactly what we are pushing now with UMA 2.0 and
>>> support for asynchronous authorization. Suppose you have a "Request
Access"
>>> button in case the user is not allowed to perform operation on a resource
>>> belonging to a different user. This button could be displayed based on a
>>> "test" authorization request to which you can also specify whether
or not
>>> you want to start an authorization flow to get approval from resource owner.
>>>
>>> Regards.
>>> Pedro Igor
>>>
>>> On Tue, Mar 6, 2018 at 4:27 PM, Corentin Dupont <
>>> corentin.dupont(a)gmail.com> wrote:
>>>
>>>> Hi all,
>>>> I have a question around the representation and result of permissions.
>>>> Say I have an application that manages socks inventory. The UI is
>>>> displaying a button to delete socks. However, some user doesn't have
>>>> the
>>>> right to delete socks!
>>>> So, I perform a request to Keycloak to get the permission.
>>>> It works well: if the user doesn't have permission, the message
>>>> "authorization denied" is displayed on the screen.
>>>>
>>>> However, it would be nicer to remove the "delete" button
entirely.
>>>> My policies are quite complex and multi-dimensional: You can delete
>>>> socks
>>>> if you are admin, but also if it belongs to you, you belong to some
>>>> groups
>>>> etc.
>>>> So anticipating the reply to an authorization request can be very hard.
>>>>
>>>> What do you suggest? Should we perform a "test" authorization
request
>>>> before display the "delete" button?
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>
>