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

[Mehdi Sheikhalishahi]

Hi Pedro,
thanks for the note.

So If we specify resource URI for Sensor1 like
databroker.iotplatform.io/Sensor1, then when a user is trying to access
this endpoint it will be hit by the permission that matches this definition.

When I am defining a resource, I cannot assign any scope, the same problem
with defininig scope-based permission. Actually, scopes do not appear by
entering the first character. Any idea?

On Thu, Mar 16, 2017 at 12:47 PM, Pedro Igor Silva <psilva at redhat.com>
wrote:

> 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
>>>>
>>>
>>>
>>
>