[keycloak-user] Keyclaok 4 and Scopes (Account Page)

Pedro Igor Silva psilva at redhat.com
Tue Apr 24 11:07:30 EDT 2018


On Tue, Apr 24, 2018 at 4:54 AM, Spike J <dev.spike.j at 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).


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


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


>
> Thanks a lot
> Spike
>
> 2018-04-23 14:07 GMT+02:00 Pedro Igor Silva <psilva at redhat.com>:
>
>>
>>
>> On Mon, Apr 23, 2018 at 6:48 AM, Spike J <dev.spike.j at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>


More information about the keycloak-user mailing list