Oops, sorry. That was a link to the old location of docs.
Here is the correct one
.
On Mon, Mar 20, 2017 at 8:30 AM, Mehdi Sheikhalishahi <
mehdi.alishahi(a)gmail.com> wrote:
Pedro, link does not work for me.
On Mon, Mar 20, 2017 at 11:58 AM, Pedro Igor Silva <psilva(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)redhat.com> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Mar 15, 2017 at 5:19 AM, Mehdi Sheikhalishahi
<
>>>>>>>>> mehdi.alishahi(a)gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>> From: Mehdi Sheikhalishahi
<mehdi.alishahi(a)gmail.com>
>>>>>>>>>> Date: Mon, Mar 13, 2017 at 6:38 PM
>>>>>>>>>> Subject: Access Control for an IoT environment
>>>>>>>>>> To: keycloak-user
<keycloak-user(a)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(a)lists.jboss.org
>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>