Re: [keycloak-dev] Sharing authorization settings across multiple clients

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