[keycloak-user] Fwd: Access Control for an IoT environment

[Pedro Igor Silva]

Mehdi, there is a URI field for that on the resource.

On Wed, Mar 15, 2017 at 12:14 PM, Mehdi Sheikhalishahi <
mehdi.alishahi at gmail.com> wrote:

> Dear Pedro,
>
> Thanks for the note. Yes, we can definitely contribute in providing our
> use cases as examples in Authz Services in KeyCloak.
>
> A question:
>
> How to represent sensors as resources? In our use case, each sensor has an
> endpoint, how we can associated a sensor with its endpoint as a resource? I
> know that we can define client, and then add resources, but I don't see any
> field for this endpoint.
>
> Cheers,
> Mehdi
>
>
>
>
>
> On Wed, Mar 15, 2017 at 3:26 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> On Wed, Mar 15, 2017 at 5:19 AM, Mehdi Sheikhalishahi <
>> mehdi.alishahi at gmail.com> wrote:
>>
>>> ---------- Forwarded message ----------
>>> From: Mehdi Sheikhalishahi <mehdi.alishahi at gmail.com>
>>> Date: Mon, Mar 13, 2017 at 6:38 PM
>>> Subject: Access Control for an IoT environment
>>> To: keycloak-user <keycloak-user at lists.jboss.org>
>>>
>>>
>>> Hi,
>>>
>>> I'd like to validate my solution based on KeyCloak for securing access to
>>> sensors.
>>>
>>> Our environment consists of a dashboard, a sensors service (a database of
>>> sensors), and KeyCloak. We need to display the list of sensors associated
>>> to the authenticated user in the dashboard, and implement Access Control
>>> to
>>> sensors. A user can have different accesses to different sensors. For
>>> simplicity, we define read, and write access types.
>>>
>>>
>>> Our solution is to use User Attributes; for that we create two user
>>> attributes for each user: one for read, and one for write. And the value
>>> of
>>> each attribute will be the list of sensors. This list states that the
>>> user
>>> has this type of access to this list of sensors. Hence, this is a
>>> database
>>> that can be used for defining policies.
>>>
>>>
>>> For presentation, we simply can read these attributes and present them in
>>> the Dashboard with appropriate columns to present read and write
>>> accesses.
>>>
>>>
>>> We need to implement another operation that is called evaluation of
>>> authorization requests. That is when a user sends a request to access a
>>> sensor for an access type (read or write), this request should be
>>> evaluated
>>> (validated) by KeyCloak. Here is the place in which KeyCloak policies
>>> come
>>> into the place. For that, we need to write a policy (an attributed based
>>> policy, or a mix kind of policy, such as JavaScript?) to evaluate if this
>>> user is authorized to perform such an operation. The output of this
>>> operation is allow or deny. If the evaluation results is allow, then the
>>> request will be sent to the database of sensors, and the result of this
>>> operation will be returned back to the Dashboard for the user.
>>>
>>>
>>> My questions are as the following:
>>>
>>>
>>> - Is this solution approach the right one?
>>>
>>
>> I think it makes more sense to represent sensors as resources in
>> Keycloak. And define read/write actions as scopes associated with these
>> scopes.
>>
>>
>>>
>>> - How we provide the access request for KeyCloak? So policy, we will have
>>> all inputs that we need for evaluation, that is user information,
>>> requested
>>> sensor, and requested access type?
>>>
>>
>> You can take a look at docs and some examples we have. But in a nutshell,
>> your policies have access to:
>>
>> - The user and the client asking for a permission (resource+scope). As
>> well any other claim associated with the access token previously issued to
>> the client on behalf of the user.
>> - The resource being requested. In your case, the resource representing a
>> sensor.
>> - The scope(s) being requested. In your case, read or write.
>>
>> A very simple config for your use case can be:
>>
>>
>> Scopes
>>
>>     READ, WRITE
>>
>> Resource:
>>
>>     Name: Sensor A
>>     Scopes: READ, WRITE
>>
>> Policy:
>>
>>     My JavaScrypt Policy
>>
>> Scope-Based Permission:
>>
>>     Name: Sensor A Read Permission
>>     Resource: Sensor A
>>     Scope: READ
>>     Apply Policies: My JavaScript Policy
>>
>> When you as permissions for Sensor A, you will get a GRANT or DENY
>> depending on the conditions you defined in My JavaScript Policy.
>>
>> You can also use a resource-based permission to enforce access to the
>> resource too, if you want to do so. I would also suggest to try out our
>> Evaluation Tool to check out how all that fits without requiring you to
>> build an application or anything else.
>>
>> Btw, I'm looking for more examples about usages of Authz Services. If you
>> can contribute with some example application based on your use case, I can
>> help you. I think this kind of IoT scenario is very interesting and should
>> provide a nice quickstart.
>>
>>
>>>
>>>
>>> Thanks,
>>>
>>> Mehdi
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>