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.
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.
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 :)
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_
services/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