I see, so I need to create "mydomain" as a resource.
But what should be the type for both "mydomain" and "myhouse"? Should
it be
something like "domain:mydomain"?
What I would like is to grant different access to users to that domain.
For example: user Bob can only view resources in domain "mydomain".
User Alice can view and delete resources in "mydomain".
Should I create a "User Policy" with the list of users that have access?
If I understand, I need to use the "resource-based" permission. However it
does not seem to let me select the scopes (as in my example: Bob can only
view, but Alice can delete).
Another question: how to invoke the API for typed resources?
I have:
curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer
$TOKEN" -d '{
"permissions" : [
{
"resource_set_name" : "Sensors",
"scopes" : [
"view"
]
}
]
}' "http://localhost:8080/auth/realms/waziup/authz/entitlement/waziup"
But this uses the name of the resource, so I am not sure. Is there a
reference for this API?
Thanks a lot
PS. I found some minor bugs related to the API, should I report them here
or create a JIRA?
On Tue, Nov 21, 2017 at 1:51 PM, Pedro Igor Silva <psilva(a)redhat.com> wrote:
Resources have a *type* field that can be used to group resources.
Permissions granted to a "typed resource" (which is created with the
resource server itself as the owner) applies to any other resource with the
same type and owned by an user. Think about a "typed resource" as a
general/parent resource.
If you have a "mydomain" typed resource and a "myhouse" resource,
sharing
the same type, any permission you apply to "mydomain" is going to be
applied to "myhouse".
Does it makes sense ?
On Mon, Nov 20, 2017 at 9:10 AM, Corentin Dupont <
corentin.dupont(a)gmail.com> wrote:
> Thanks for the answer.
> My plan is to make authorizations based on groups of resources, that we
> call "domains".
> Basically, when a user creates a resource, he can decide to put it in an
> existing domain.
> The URL reflects that domain:
>
>
http://www.example.com/api/v1/domains/mydomain/houses/myhouse
>
> The user can also create domains with the domains endpoint:
>
> POST
http://www.example.com/api/v1/domains/
>
> What is not clear for me is how users can get access to domains.
> Probably users can have an attribute "domains", with the list of domains
> they have access to?
> Or should a domain be represented in Keycloak as a resource?
> In this case, should we create roles to access that domain?
> For example, the role "admin-mydomain" ?
>
> Or should it be implemented with user groups in Keycloak? Or with User
> policies?
>
>
>
> On Fri, Nov 17, 2017 at 9:06 PM, Pedro Igor Silva <psilva(a)redhat.com>
> wrote:
>
>> Right now you can't do it. This is all about the work we are doing to
>> better support UMA protocol. Soon you'll be able to let your users to
>> manage their resources (and their policies) from Keycloak Account Service,
>> grant and revoke access to other users, authorization flows. We are really
>> missing this.
>>
>> However, I think you can try to use the Policy Management API. It
>> provides a RESTful API that you can use to manage permissions and policies.
>> As an example
https://github.com/pedroigor/keycloak/blob/cedc095a9
>> c50a1d16482acbbc9876de1730c9fb1/testsuite/integration-arquil
>> lian/tests/base/src/test/java/org/keycloak/testsuite/admin/
>> client/authorization/UserPolicyManagementTest.java. There are other
>> tests in the same package for other permission and policy types.
>>
>> Please, let me know about your achievements if you start doing something
>> with the Policy Management API. Any feedback is welcome and will probably
>> help with the work I mentioned before around UMA.
>>
>> On Fri, Nov 17, 2017 at 4:59 PM, Corentin Dupont <
>> corentin.dupont(a)gmail.com> wrote:
>>
>>> Hi guys,
>>> is it possible for an application user to grant some authorizations to
>>> another user?
>>> For example in the photoz example, how can I give access to my albums
>>> to another user?
>>> What would be the mechanism?
>>>
>>> Thanks a lot
>>> Corentin
>>>
>>
>>
>