[keycloak-dev] Sharing authorization settings across multiple clients

Marek Posolda mposolda at redhat.com
Wed Mar 21 15:52:22 EDT 2018


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 <mailto: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
>     <mailto: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 <mailto: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 <mailto:psilva at redhat.com>> wrote:
>
>                 On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda
>                 <mposolda at redhat.com <mailto: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
>                 <mailto:keycloak-dev at lists.jboss.org>
>                 >>
>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>                 <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>                 >>
>                 >
>                 >
>                 >
>                 _______________________________________________
>                 keycloak-dev mailing list
>                 keycloak-dev at lists.jboss.org
>                 <mailto:keycloak-dev at lists.jboss.org>
>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>                 <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
>
>



More information about the keycloak-dev mailing list