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

That is the idea. On Wed, Mar 21, 2018 at 11:13 AM, Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@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(a)redhat.com <mailto:psilva@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(a)redhat.com <mailto:sthorger@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(a)redhat.com <mailto:psilva@redhat.com>> wrote: On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>