[keycloak-user] Securing RESTful API Best Practices

Wed May 22 08:12:38 EDT 2019

Sure. I'm not telling you that you should not use us to address your
requirements, but that you should take into account whether or not you are
using our authorization capabilities to process business rules, which is
not our focus. I wanted to let you know about other projects that are
targeted for this type of work. Sometimes, the borderline between security
constraints and business rules are very clear when you are externalizing
authorization from your application.

But yeah, I think both approaches can work for you. The data filter
approach is could be very handy in order to filter resources that users can
access. So if you are able to group your users into groups and then write
policies that push back a claim based on the user membership, then you
should be able to keep your policies simple. This is probably the optimal
solution because it avoids additional requests from the server for checking
whether or not the user has access to a resource.

On the other hand, you can use resource types. Or even have resources in
Keycloak that represent your different resource sets. Based on the
permissions within the token you should also be able to build the query
accordingly in your application.

On Tue, May 21, 2019 at 6:41 PM Farzad Panahi <farzad.panahi at gmail.com>
wrote:

> Thanks Pedro. I really appreciate your reply.
>
> I think arbitrary claims are what I need to pass the filtering required to
> the backend (if I can generate those claims). Also resource types look
> interesting. I think as you said I can use that to group my resources.
> These two should solve my problems at hand.
>
> That would be also great if you could elaborate on what you meant by
> "security constraints" vs "business rules". I just want to have a better
> understanding of Keycloak.
> My understanding is that Keycloak is an identity and "access management"
> system. And when it comes to "access management" my understanding is that
> it means "who" has "what" access to "which" resource under "what
> conditions".
> If this definition is true, wouldn't "who has access to which resources"
> be a security constraint under Keycloak's authorization model?
>
> As you said I might need to look into other solutions but I before I do
> that I want to make sure I really cannot do what I want to do with Keycloak
> and I really cannot implement my requirements under Keycloal's
> authorization model, since I have already happily invested lots of time on
> Keycloak :)
>
>
>
> On Tue, May 21, 2019 at 11:35 AM Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Hi Farzad,
>>
>> Sorry for the late reply.
>>
>> Our authorization model is targeted for enforcing security-related
>> constraints, not business rules. Maybe you could consider Drools/BRMS.
>>
>> Some time ago we had a discussion about data filtering and how to fetch
>> resources based on policy decisions. If you look at our documentation [1]
>> you'll see that policies can push arbitrary claims back to your application
>> when granting access to a permission. This capability allows you to send a
>> specific claim along with the permission that represents some filter that
>> you can use to query your database.
>>
>> As a result, you'll have within your token something like:
>>
>> "permissions": [
>>     {
>>       "resource_id": "90ccc6fc-b296-4cd1-881e-089e1ee15957",
>>       "resource_name": "Book Resource",
>>       "claims": ["data.filter": ["book.type = 'foo' or book.type =
>> 'bar'"]]
>>     }
>>   ]
>>
>> We do have a "resource group" concept. Resources can have a type and you
>> can also have a single resource representing a set of one or more "real"
>> resources.
>>
>> [1]
>> https://www.keycloak.org/docs/latest/authorization_services/index.html#pushing-arbitrary-claims-to-the-resource-server
>>
>> On Tue, May 21, 2019 at 3:14 PM Farzad Panahi <farzad.panahi at gmail.com>
>> wrote:
>>
>>> Any hint or example project to look at would really help to put me in the
>>> right direction.
>>>
>>> Should I post this question with a better and more specific title with
>>> more
>>> elaborate body to present the question better?
>>>
>>> On Fri., May 17, 2019, 1:21 p.m. Farzad Panahi, <farzad.panahi at gmail.com
>>> >
>>> wrote:
>>>
>>> > This is exactly where I want to use Keycloak to set this business
>>> > rule/mapping. Basically I need to associate each user with a subset of
>>> B
>>> > (books) to which the user has access to. This association is not based
>>> on
>>> > roles or groups. It is based on individual users.
>>> > That's why I was thinking that the only way I can think of doing this
>>> to
>>> > add every individual book as a resource in Keycloak and then I have to
>>> > create a permission for each of them to grant access to any individual
>>> user.
>>> > It would help if Keycloak had a concept like a resource group I guess.
>>> > Then I could put all those resources in a resource group and grant
>>> access
>>> > to that resource group for an individual user.
>>> > Then in order to see which resources each user has access to, I need to
>>> > query Keycloak somehow (I need to figure out how exactly) and get the
>>> > resources that user has access to, and return only those resources for
>>> that
>>> > user.
>>> >
>>> > That's what I can think of right now. I am just wondering if there is a
>>> > better way to do this sort of resource oriented access control where
>>> each
>>> > user has access to specific set of resources only.
>>> >
>>> >
>>> >
>>> > On Fri, May 17, 2019 at 11:45 AM Pedro Igor Silva <psilva at redhat.com>
>>> > wrote:
>>> >
>>> >> Sorry, but is still not clear to me how a "user has access to a
>>> subset of
>>> >> B" is this access based on roles, groups or any other information
>>> that you
>>> >> gather from the context ? I'm wondering if this is not a business rule
>>> >> instead ....
>>> >>
>>> >> On Fri, May 17, 2019 at 1:42 PM Farzad Panahi <
>>> farzad.panahi at gmail.com>
>>> >> wrote:
>>> >>
>>> >>> Hi Pedro,
>>> >>>
>>> >>> The user is not the book owner. You can think about it this way that
>>> if
>>> >>> B is the set of all books then each user has access to a subset of B
>>> such
>>> >>> that these subsets are not mutually exclusive and do overlap.
>>> >>>
>>> >>> On Fri., May 17, 2019, 6:51 a.m. Pedro Igor Silva, <
>>> psilva at redhat.com>
>>> >>> wrote:
>>> >>>
>>> >>>> Hi Farzad,
>>> >>>>
>>> >>>> How do you check if a user has access to a book ? Is the user the
>>> book
>>> >>>> owner or you have more conditions that should be taken into account
>>> to
>>> >>>> grant access to books ?
>>> >>>>
>>> >>>> [1]
>>> >>>>
>>> https://www.keycloak.org/docs/latest/authorization_services/index.html#examples
>>> >>>>
>>> >>>>
>>> >>>> On Thu, May 16, 2019 at 8:42 PM Farzad Panahi <
>>> farzad.panahi at gmail.com>
>>> >>>> wrote:
>>> >>>>
>>> >>>>> Hi,
>>> >>>>>
>>> >>>>> I am very new to Keycloak. I have a RESTful API implemented with
>>> >>>>> json:api
>>> >>>>> <https://jsonapi.org/> spec which I want to secure using Keycloak.
>>> >>>>>
>>> >>>>> I just want to ask the Keycloak community for best practices when
>>> it
>>> >>>>> comes
>>> >>>>> to securing RESTful APIs.
>>> >>>>>
>>> >>>>> My endpoints will be something like:
>>> >>>>> GET /api/books --> return all books the user has access for
>>> >>>>> GET /api/books/123 --> return book with id = 123
>>> >>>>>
>>> >>>>> My challenge now is to figure out how to define resources in
>>> Keycloak.
>>> >>>>> Should I add all my books as resources to Keycloak? And then
>>> define the
>>> >>>>> permission between each user and resource?
>>> >>>>>
>>> >>>>> What would be the best practice to implement "GET /api/books" to
>>> return
>>> >>>>> only the books the logged in user has access to? Should I query the
>>> >>>>> Keycloak API to get all the resources the logged in user has access
>>> >>>>> to, in
>>> >>>>> the backend?
>>> >>>>>
>>> >>>>> Thanks
>>> >>>>>
>>> >>>>> Farzad
>>> >>>>> _______________________________________________
>>> >>>>> keycloak-user mailing list
>>> >>>>> keycloak-user at lists.jboss.org
>>> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> >>>>>
>>> >>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>