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

Mehdi Sheikhalishahi mehdi.alishahi at gmail.com
Fri Mar 17 14:33:03 EDT 2017


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


More information about the keycloak-user mailing list