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

[Pedro Igor Silva]

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
>