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

[Mehdi Sheikhalishahi]

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