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

[Pedro Igor Silva]

Hey Mehdi.

Now I see ... We did have an issue on scope-based permission UI. But we
have fixed in 2.5.5.Final as well some improvements to the policy
evaluation engine when dealing with scope permissions.

Regarding client scopes, they are a different thing. They basically map to
the OAuth2 scopes and roles in your client while authorization scopes are
not really related with OAuth2 scopes or roles but with actions or any
other representation of something you resource has/provides.

This is the main concept behind fine-grained permissions in Keycloak, where
your authorization scopes don't represent an authorization data by
themselves but something protected by your policies.

Regards.
Pedro Igor

On Thu, Mar 16, 2017 at 2:04 PM, Mehdi Sheikhalishahi <
mehdi.alishahi at gmail.com> wrote:

> I upgraded to 2.5.5. With this version, I can see Authorization Scopes,
> but not the client scopes. Is this the expected behavior?
>
> One note: our database of sensors that we are considering as Resource
> Server, does not provide any OAuth 2.0 implemenation. Can KC act also as a
> resource server?
>
> On Thu, Mar 16, 2017 at 5:48 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> What is the version you are using ? I have no idea why are not able
>> select scopes in both cases. Have you created your scopes ?
>>
>> Regards.
>> Pedro Igor
>>
>> On Thu, Mar 16, 2017 at 10:16 AM, Mehdi Sheikhalishahi <
>> mehdi.alishahi at gmail.com> wrote:
>>
>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>