2018-04-24 17:07 GMT+02:00 Pedro Igor Silva <psilva(a)redhat.com>:
On Tue, Apr 24, 2018 at 4:54 AM, Spike J <dev.spike.j(a)gmail.com> wrote:
> Hi Pedro,
>
> thanks for your replies.
>
> according to:
>
> 1. Are there any plans to create scopes on the account page? In our case
> every service-owner should be able to decide if he wants to protect each
> REST endpoint with its own scope or a single scope for all and so on. So it
> would be nice that he could just create a scope from within his account
> page and does not have to ask us (admins) to create that scope for him.
> Otherwise we would create a separate Webapp just for creating/deleting
> scopes.
>
I guess your "users" are not actually end-users, right ? I mean, they are
developers responsible for a service in your platform ?
If that is true, the account page is meant for end-users. Where the
resources and scopes they can manage are actually managed by a resource
server.
As you might know, we provide APIs that you can use to build functionality
to manage things on the server (Resources, scopes, policies, permissions,
etc).
Yes, that is exactly our case. Couldn´t this be just an additional role
"manage-resources" for users for the account-page like
"view-profile"/"manage-account" in "Role Mappings"?
>
> 2. I understand from the UMA perspective how to apply for a scope through
> the ticketing process. But as a requester for a scope (to access a REST
> endpoint in our case) I would like to see all scopes that are available to
> apply for certain scopes directly from the account page. For me the account
> page seems kind of restricted as I can allow or give scopes, but can not
> apply for one. And on the other hand (referring to 1.) I can manage
> ressources and scopes but can not create them.
>
I see. Yeah, users can not "ask" for a resource/scope from the account
page. They can "grant" access to their resources/scopes. This is not
something hard to support, we could provide something to let users "ask"
for access.
The thing is that per UMA, client applications are responsible for
managing these "authorization requests". User is navigating through your
application and then he wants to access some protected resource he is not
allowed to access. Being this resource owned by a different user, your
client application can "ask" the owner to allow the user to access the
resource by "submitting" a authorization request which the owner can
"approve" or "deny".
That is the flow we support. I`m not sure how we could support "asking"
permissions directly through account page thoughj ....
I think our usecase is a little bit different to the "common" usecase for
keycloak. But having keycloak to protect our REST endpoints would make us
always fail to access that endpoint first and then having a ticket send to
the owner. Would be possible but a little bit ugly to let all calls "fail"
first. If there was something like an "apply for" form this would be
awesome. Otherwise, again, we would build a webapp in front of keycloak to
do something like this (similar to 1). But of course we would prefer a
keycloak-native solution.
>
> 3. We managed to set up a script-based policy with checking for owner
> and/or claims to a scope. I think that should fullfill our requirements.
>
> 4. Thanks, we will have a closer look at that.
>
> 5. We tried to check our entire infrastructure with Postman first.
> Therefore, we were looking for an endpoint that gives us the granted
> scopes. But I agree, if the policy enforcer does that then there is no need
> for anything else :)
>
In next release (Beta2) we are going to push several improvements to
policy enforcer. Some of them include:
* Allow clients to not use RPTs to access a resource server but just the
access token. In this case, the PEP will do the job to query permissions
from the server for each request.
* Allow resource servers to push arbitrary claims from different sources
at runtime (request, external http service, etc) and send these claims to
policies in order to provide a more information about the transaction in
course.
* Allow resource servers to configure cache of paths and resources mapped
from the server. Or disable cache completely.
* Allow resources to load resources on-demand from Keycloak. Today you
need to either load everything during deployment or specify paths in
keycloak.json.
Sounds great, thanks for the update :)
>
> Thanks a lot
> Spike
>
> 2018-04-23 14:07 GMT+02:00 Pedro Igor Silva <psilva(a)redhat.com>:
>
>>
>>
>> On Mon, Apr 23, 2018 at 6:48 AM, Spike J <dev.spike.j(a)gmail.com> wrote:
>>
>>> Hi together,
>>>
>>> we are trying to use Keycloak in a microservice environment with
>>> different
>>> admins for different services. Therefore, we want to use the scopes that
>>> can be manages in the account pages for each REST endpoint in each
>>> service.
>>>
>>> But there are a few questions we are not able to figure out:
>>> 1. can we create resources/scopes in the account-page or only manage
>>> existing scopes?
>>>
>>
>> Users are only allowed to manage existing resources and scopes. Where
>> these resources/scopes were previously created on the resource server.
>>
>>
>>> 2. is there any way to have an overview with all scopes/resources to
>>> apply
>>> for or is the common usecase that you fail to get access and then have
>>> to
>>> sent a ticket somehow manually or call the admin to get the scope?
>>>
>>
>> This functionality is based on UMA protocol to enable users to manage
>> their own resources. From a client perspective, you will be receiving a
>> permission ticket with the necessary information to request access to a
>> protected resource. But as a resource server you are allowed to query the
>> Resource Registration Endpoint and query for resources.
>>
>>
>>> 3. is there no way to make policies based on scopes? There are only
>>> permissions based on scopes. But somehow we run in circles, as we want
>>> to
>>> use the scopes as permissions and don´t want to protect the scopes
>>> based on
>>> anything else than the account-page ("My Resources").
>>>
>>
>> So, you don't want any permission/policies but just rely on the
>> permissions granted your users via account page ?
>>
>> I don't have tests for this scenario, but I think we can do that.
>>
>>
>>> 4. is there any easy annotation to check for scopes in spring? I always
>>> see
>>> "hasRole", but when we only work with scopes we would expect a
>>> "hasScope".
>>> Do we have to add roles with "Scope Param Required"?
>>>
>>
>> When you enable the policy enforcer to your application you are provided
>> with an Authorization Context [1]. It is basically an object that provides
>> access to the permissions granted by the server (resource and scopes).
>>
>> [1]
https://www.keycloak.org/docs/latest/authorization_servi
>> ces/index.html#_enforcer_authorization_context
>>
>>
>>> 5. where do we actually check for scopes allowed for a user? When we get
>>> the token - depending on the policy enforcement - we either get always
>>> the
>>> scope or never and not based on what is configured on the account-page.
>>>
>>
>> I may be missing something here, but usually you don't need to manually
>> check for resources/scopes as this is the job of the policy enforcer. But
>> again, you can have access to all permissions granted from the
>> Authorization Context.
>>
>>
>>>
>>> Would be great to get some feedback as we really struggle with those
>>> topics
>>> for several time now.
>>> I am compiling the newest keycloak all the time -> Version 4 beta.
>>>
>>> Thanks in advance and kind regards
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>