[keycloak-dev] Sharing authorization settings across multiple clients

Wed Mar 21 10:13:23 EDT 2018

Having a separate entry for authz might make a lot of sense. To take that
to the extreme you could then share everything between clients right?
Resources, policies, you name it.

On 21 March 2018 at 13:30, Pedro Igor Silva <psilva at redhat.com> wrote:

> If you also agree we should have a specific thing for authz services, I'm
> OK with it.
>
> In fact, the first version of authorization services had its own menu item
> in the admin console. Before merging it we found that include it as a tab
> in Client UI was better.
>
> It should not require too much time to move the authorization bits from
> Client UI to its own menu item in the admin console. Main work will be docs
> and reviewing quickstarts. Does "Authorization Services" sounds like a good
> name for this menu item ?
>
>
>
> On Tue, Mar 20, 2018 at 5:54 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> I agree that this doesn't fit into client scope.
>>
>> Perhaps we should have kept client templates and just removed protocol
>> mappers and scope from it. Not sure it has a wider use-cases than
>> authorization services though. So perhaps the best would be to have some
>> sort of authorization services specific thing?
>>
>> On 20 March 2018 at 21:16, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda <mposolda at redhat.com>
>>> wrote:
>>>
>>> > The difference between clientScopes and clientTemplates is, that
>>> > client-clientTemplate mapping is 1:1 . But client-clientScope mapping
>>> will
>>> > be 1:N.
>>> >
>>> > So in the PR I've removed some configuration things from clientTemplate
>>> > due the potential conflicts with 1:N mapping. For example if client
>>> would
>>> > inherit from 2 client scopes called "scope1" and "scope2" . And
>>> "scope1"
>>> > would have "Login theme" value "sunrise", but "scope2" would have
>>> "Login
>>> > theme" value "keycloak". Then client wouldn't know if it should use
>>> > "sunrise" or "keycloak" theme.
>>>
>>>
>>> > Those configuration switches just don't fit well to the client scope
>>> > model. So I removed login theme override from admin console and some
>>> > switches from clientTemplateModel, which were defacto never supported
>>> by
>>> > admin console and admin REST API and defacto never worked (For example
>>> > clientTemplate had switches like standardFlowEnabled,
>>> implicitFlowEnabled
>>> > etc.).
>>> >
>>> >
>>> > ProtocolMappers and "Role scope mappings" fit well into the
>>> > clientScopeModel as they "add" things into the client. Basically
>>> client use
>>> > all protocolMappers defined on itself and on all "parent" client
>>> scopes.
>>> >
>>> > For resources, authorization scopes and policies, those also "add"
>>> things
>>> > if I understand correctly? Basically client will use all policies
>>> declared
>>> > on himself and on all the parent client scopes. So maybe authorization
>>> > settings can be also added to client scopes?
>>> >
>>>
>>> Yeah, they add things to a client. So a client may have its own resources
>>> and policies + the ones inherited by a template/scope. In this particular
>>> case, we are basically sharing common settings across multiple clients.
>>> There is no need for a scope definition.
>>>
>>>
>>> >
>>> > I am just not sure if it fits into the "optional" scopes as it would
>>> mean
>>> > that some policies (and resources and authorization scopes) will be
>>> used
>>> > based on the value of "scope" parameter. But maybe yes as accessToken
>>> and
>>> > the authorization tokens will have "scope" parameter on it, so the
>>> adapter
>>> > will be able to check what policies were used to issue the token and
>>> > eventually throw the authorization error if used "scope" is
>>> insufficient?
>>> >
>>> > The other possibility is to use something different than client scopes.
>>> > Either revert clientTemplates back (I can still update PR to have both
>>> > clientTemplates and clientScopes models available and have both in
>>> admin
>>> > console, but it will take few days of work and I won't be able to do
>>> that
>>> > in next few weeks). Or do some other thing for authorization similar to
>>> > what clientTemplate was before?
>>>
>>>
>>> > ATM I think that having resources + authorizationScopes + policies
>>> defined
>>> > on clientScopes would work. But I may miss some contexts. You know
>>> more if
>>> > those authorization settings fit to the clientScope model or not.
>>> >
>>>
>>> IMO, my use case does not fit into client scopes, at all. What we need
>>> is a
>>> place where we can define common settings for multiple clients. In fact,
>>> I
>>> think this is not only useful for this particular use case but wherever
>>> you
>>> want to allow users to define common settings for clients within the same
>>> realm.
>>>
>>> Sorry for starting this thread so late. I would say that client templates
>>> would fit nice, but let's see what others think about it. Not sure about
>>> something specific for authorization settings. However ff we decide for
>>> something specific, we should probably move authorization stuff to its
>>> own
>>> menu item in admin console.
>>>
>>> But I do see value in client templates as a way to define common settings
>>> for clients ...
>>>
>>>
>>>
>>> >
>>> > Marek
>>> >
>>> > Dne 20.3.2018 v 15:48 Pedro Igor Silva napsal(a):
>>> >
>>> >> Hi,
>>> >>
>>> >> I was investigating how we could share authorization settings
>>> (resources,
>>> >> scopes, and specially policies) across multiple clients.
>>> >>
>>> >> Until now, I was considering using Client Templates for that. But now
>>> that
>>> >> Client Templates are gone in favor of Client Scopes, I'm not sure
>>> where
>>> >> this functionality fits in.
>>> >>
>>> >> Any suggestion on how we can support this ? IMO, better would be avoid
>>> >> another item on the menu for this. But I can't envision other way to
>>> do it
>>> >> ....
>>> >>
>>> >> Regards.
>>> >> Pedro Igor
>>> >> _______________________________________________
>>> >> keycloak-dev mailing list
>>> >> keycloak-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>
>>> >
>>> >
>>> >
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>