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

[Pedro Igor Silva]

Please, take a look on our docs [1] and examples. If they are not good
enough to get you going, please open issues to that doc so we can improve
it.

[1]
https://www.gitbook.com/book/keycloak/authorization-services-guide/details

Regards.
Pedro Igor

On Fri, Mar 17, 2017 at 3:33 PM, Mehdi Sheikhalishahi <
mehdi.alishahi at gmail.com> wrote:

> Hi Pedro
> Thanks for the note.
>
> So as I understand I should define authorization scopes that are specific
> to keycloak.
>
> How can we understand which scope a user is asking?
>
> How to enforce policies?
>
> On Mar 17, 2017 1:09 PM, "Pedro Igor Silva" <psilva at redhat.com> wrote:
>
>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>