[keycloak-dev] Sharing authorization settings across multiple clients

[Pedro Igor Silva]

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>
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> 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
>>
>
>