[keycloak-dev] Sharing authorization settings across multiple clients

[Stian Thorgersen]

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
>