[keycloak-user] Viewing permissions

[Corentin Dupont]

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.

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 at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>