[keycloak-dev] Sharing authorization settings across multiple clients

[Pedro Igor Silva]

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