[keycloak-dev] Sharing authorization settings across multiple clients

[Pedro Igor Silva]

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