[keycloak-dev] Sharing authorization settings across multiple clients

[Pedro Igor Silva]

I think we decided in another thread to have a specific menu item for
authorization settings. You won't need to change what you did.

I've created https://issues.jboss.org/browse/KEYCLOAK-6956.

On Wed, Mar 21, 2018 at 4:52 PM, Marek Posolda <mposolda at redhat.com> wrote:

> Ok, if you think that having authz as first class citizen, then let's go
> with it.
>
> Still, if you want to revert clientTemplate, it's not yet late :) But
> clientScope PR will need to be re-done to have both clientTemplate and
> clientScope exists together. Question is, if we have some other similar
> use-case (some common configuration to be shared between multiple clients).
> But looks that no? Until now, we used it just for login theme, which was
> quite a minor thing.
>
> Marek
>
>
> Dne 21.3.2018 v 15:29 Pedro Igor Silva napsal(a):
>
> That is the idea.
>
> On Wed, Mar 21, 2018 at 11:13 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> 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
>>>>>
>>>>
>>>>
>>>
>>
>
>