[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