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

Spike J dev.spike.j at gmail.com
Wed Apr 25 03:00:17 EDT 2018


2018-04-24 17:07 GMT+02:00 Pedro Igor Silva <psilva at redhat.com>:

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

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