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

Mon Mar 20 18:20:42 EDT 2017

Oops, sorry. That was a link to the old location of docs.

Here is the correct one
https://www.keycloak.org/docs/3.0/authorization_services/index.html.

On Mon, Mar 20, 2017 at 8:30 AM, Mehdi Sheikhalishahi <
mehdi.alishahi at gmail.com> wrote:

> Pedro, link does not work for me.
>
> On Mon, Mar 20, 2017 at 11:58 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> 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-serv
>> ices-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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>