[keycloak-user] Securing RESTful API Best Practices

Tue May 28 13:49:59 EDT 2019

That would be really helpful. Is there an open ticket for it that I can
watch?

So if I can't granted permissions on the policy engine then I don't have
any other option but doing this on the backend bycalling the Protection
API, right?

On Tue., May 28, 2019, 5:16 a.m. Pedro Igor Silva, <psilva at redhat.com>
wrote:

> Not right now because policies are basically processing permissions
> (requested resource + scope) on a per-resource basis. In the future, we are
> looking forward to making the policy engine more flexible so that you could
> perform resource-less evaluation based on any data you include in an
> authorization request.
>
> On Tue, May 28, 2019 at 3:28 AM Farzad Panahi <farzad.panahi at gmail.com>
> wrote:
>
>> Thanks Pedro.
>>
>> I am thinking to fetch all the permissions granted for the user and from
>> there I can get all the resource names (books) and scopes user has access
>> for.
>>
>> I have done this by getting the RPT from the Protection API in the
>> backend and iteration over the "permissions". But I am thinking to cut a
>> round-trip request and do this in the policy and push the resource names
>> (with granted permission) as an arbitrary claim. But as far as I understand
>> I only have access to Evaluation instance in the policy.  Is there a way to
>> get all the "permissions granted" for a user, in the policy?
>>
>>
>> Cheers
>>
>> Farzad
>>
>>
>>
>> On Wed, May 22, 2019 at 5:12 AM Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>
>>> 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
>>>>>>
>>>>>