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

[Mehdi Sheikhalishahi]

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