9:48 a.m.
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
11:32 a.m.
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?
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.
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
3:16 p.m.
On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda <mposolda(a)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
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
3:54 p.m.
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> wrote:
On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda
<mposolda(a)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
>> 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
7:30 a.m.
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>
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> wrote:
> On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda <mposolda(a)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
> >> 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
>
9:13 a.m.
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> 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>
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> wrote:
>
>> On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda <mposolda(a)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
>> >> 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
>>
>
>
9:29 a.m.
That is the idea.
On Wed, Mar 21, 2018 at 11:13 AM, Stian Thorgersen <sthorger(a)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> 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>
> 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> wrote:
>>
>>> On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda <mposolda(a)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
>>> >> 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
>>>
>>
>>
>
2:52 p.m.
Ok, if you think that having authz as first class citizen, then let's go
with it.
Still, if you want to revert clientTemplate, it's not yet late :) But
clientScope PR will need to be re-done to have both clientTemplate and
clientScope exists together. Question is, if we have some other similar
use-case (some common configuration to be shared between multiple
clients). But looks that no? Until now, we used it just for login theme,
which was quite a minor thing.
Marek
Dne 21.3.2018 v 15:29 Pedro Igor Silva napsal(a):
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>
3:26 p.m.
I think we decided in another thread to have a specific menu item for
authorization settings. You won't need to change what you did.
I've created https://issues.jboss.org/browse/KEYCLOAK-6956.
On Wed, Mar 21, 2018 at 4:52 PM, Marek Posolda <mposolda(a)redhat.com> wrote:
Ok, if you think that having authz as first class citizen, then
let's go
with it.
Still, if you want to revert clientTemplate, it's not yet late :) But
clientScope PR will need to be re-done to have both clientTemplate and
clientScope exists together. Question is, if we have some other similar
use-case (some common configuration to be shared between multiple clients).
But looks that no? Until now, we used it just for login theme, which was
quite a minor thing.
Marek
Dne 21.3.2018 v 15:29 Pedro Igor Silva napsal(a):
That is the idea.
On Wed, Mar 21, 2018 at 11:13 AM, Stian Thorgersen <sthorger(a)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> 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>
>> 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> wrote:
>>>
>>>> On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda
<mposolda(a)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
>>>> >> 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
>>>>
>>>
>>>
>>
>
3057
days inactive
3058
days old
8 comments
3 participants
participants (3)
-
Marek Posolda -
Pedro Igor Silva -
Stian Thorgersen