5:11 p.m.
This is something for 4.0
Was thinking that we should rename Client Templates to Client Scopes.
For oauth, oidc, and token exchange client asks for a specific scope
with the "scope" parameter. This "scope" parameter would be the name
of a client-id or a client scope (formerly client emplates. Clients
will be granted access to scopes in the admin console. Probably
through authz services.
--
Bill Burke
Red Hat
9:24 a.m.
Interesting idea. That might just work and be a nice and easy way to add
proper support for OAuth/OIDC scope.
On 25 September 2017 at 17:11, Bill Burke <bburke(a)redhat.com> wrote:
This is something for 4.0
Was thinking that we should rename Client Templates to Client Scopes.
For oauth, oidc, and token exchange client asks for a specific scope
with the "scope" parameter. This "scope" parameter would be the
name
of a client-id or a client scope (formerly client emplates. Clients
will be granted access to scopes in the admin console. Probably
through authz services.
--
Bill Burke
Red Hat
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:38 p.m.
Maybe want to allow client scopes to define their own roles too. Then
we have a role namespace as well. Could even think about removing
realm roles if we do this.
On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen <sthorger(a)redhat.com> wrote:
Interesting idea. That might just work and be a nice and easy way to
add
proper support for OAuth/OIDC scope.
On 25 September 2017 at 17:11, Bill Burke <bburke(a)redhat.com> wrote:
>
> This is something for 4.0
>
> Was thinking that we should rename Client Templates to Client Scopes.
> For oauth, oidc, and token exchange client asks for a specific scope
> with the "scope" parameter. This "scope" parameter would be the
name
> of a client-id or a client scope (formerly client emplates. Clients
> will be granted access to scopes in the admin console. Probably
> through authz services.
>
>
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
Red Hat
9:35 a.m.
Interesting. So client templates could become a very flexible thing that
covers many uses. So one single concept could cover:
* Templates as today
* Scope
* Namespaces
I like the idea, but the devil is in the details. How would it end up
looking. Would it be easy to use.
On 27 September 2017 at 19:38, Bill Burke <bburke(a)redhat.com> wrote:
Maybe want to allow client scopes to define their own roles too.
Then
we have a role namespace as well. Could even think about removing
realm roles if we do this.
On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> Interesting idea. That might just work and be a nice and easy way to add
> proper support for OAuth/OIDC scope.
>
> On 25 September 2017 at 17:11, Bill Burke <bburke(a)redhat.com> wrote:
>>
>> This is something for 4.0
>>
>> Was thinking that we should rename Client Templates to Client Scopes.
>> For oauth, oidc, and token exchange client asks for a specific scope
>> with the "scope" parameter. This "scope" parameter would be
the name
>> of a client-id or a client scope (formerly client emplates. Clients
>> will be granted access to scopes in the admin console. Probably
>> through authz services.
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
--
Bill Burke
Red Hat
2:52 p.m.
I think all these concepts under a single umbrella is confusing.
Regarding roles and scopes ....
IMO, roles and scopes are separated things. It would be nice if we had a
specific area for Scope Mapping, where from there I could create scopes and
manage their configuration (consent, param required, etc), associate scopes
with roles (and not turn roles into scopes) and associate mappers with
scopes.
And also push scopes into a separated claim within tokens.
On Thu, Sep 28, 2017 at 4:35 AM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
Interesting. So client templates could become a very flexible thing
that
covers many uses. So one single concept could cover:
* Templates as today
* Scope
* Namespaces
I like the idea, but the devil is in the details. How would it end up
looking. Would it be easy to use.
On 27 September 2017 at 19:38, Bill Burke <bburke(a)redhat.com> wrote:
> Maybe want to allow client scopes to define their own roles too. Then
> we have a role namespace as well. Could even think about removing
> realm roles if we do this.
>
> On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
> > Interesting idea. That might just work and be a nice and easy way to
add
> > proper support for OAuth/OIDC scope.
> >
> > On 25 September 2017 at 17:11, Bill Burke <bburke(a)redhat.com> wrote:
> >>
> >> This is something for 4.0
> >>
> >> Was thinking that we should rename Client Templates to Client Scopes.
> >> For oauth, oidc, and token exchange client asks for a specific scope
> >> with the "scope" parameter. This "scope" parameter
would be the name
> >> of a client-id or a client scope (formerly client emplates. Clients
> >> will be granted access to scopes in the admin console. Probably
> >> through authz services.
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> Red Hat
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:38 p.m.
Although unifying all of this is probably very elegant from a code perspective, I agree
with Pedro. For me scopes and roles are two different concepts. Scopes being mainly for
the external client/user view. Especially when you look into the direction of GDPR or UMA
2.0 client scopes, they could be a means to describe privacy-relevant information (e.g.
what kind of data, the purpose of accessing it, associated descriptions). Latest at that
point, still calling this role and managing it the same way as roles will probably be very
confusing...
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer
Kallenbach, Michael Hahn
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org]
On Behalf Of Pedro Igor Silva
Sent: Donnerstag, 28. September 2017 14:53
To: Thorgersen, Stian <stian(a)redhat.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] rename client templates to scope?
I think all these concepts under a single umbrella is confusing.
Regarding roles and scopes ....
IMO, roles and scopes are separated things. It would be nice if we had a specific area for
Scope Mapping, where from there I could create scopes and manage their configuration
(consent, param required, etc), associate scopes with roles (and not turn roles into
scopes) and associate mappers with scopes.
And also push scopes into a separated claim within tokens.
On Thu, Sep 28, 2017 at 4:35 AM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
Interesting. So client templates could become a very flexible thing
that covers many uses. So one single concept could cover:
* Templates as today
* Scope
* Namespaces
I like the idea, but the devil is in the details. How would it end up
looking. Would it be easy to use.
On 27 September 2017 at 19:38, Bill Burke <bburke(a)redhat.com> wrote:
> Maybe want to allow client scopes to define their own roles too.
> Then we have a role namespace as well. Could even think about
> removing realm roles if we do this.
>
> On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen
> <sthorger(a)redhat.com>
> wrote:
> > Interesting idea. That might just work and be a nice and easy way
> > to
add
> > proper support for OAuth/OIDC scope.
> >
> > On 25 September 2017 at 17:11, Bill Burke <bburke(a)redhat.com> wrote:
> >>
> >> This is something for 4.0
> >>
> >> Was thinking that we should rename Client Templates to Client Scopes.
> >> For oauth, oidc, and token exchange client asks for a specific
> >> scope with the "scope" parameter. This "scope"
parameter would
> >> be the name of a client-id or a client scope (formerly client
> >> emplates. Clients will be granted access to scopes in the admin
> >> console. Probably through authz services.
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> Red Hat
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat
>
_______________________________________________
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:12 a.m.
The term "scope" has two meanings within Keycloak. That's confusing.
Firstly scope means a "client is allowed to get this role", but then
there's the other meaning coming from OAuth which means "client is
requesting access to this set of resources". So let's call them "roles
scope" for the first and "oauth scope" for the second in this mail to
remove confusion around that.
With regards to Bill's suggestion I don't find it confusing at all. A
"client template" is really only a grouping mechanism for protocol mappers,
roles and "role scopes". It's currently only used to allow clients to share
this config, but if you think about what properly introducing "oauth
scopes" properly would mean to Keycloak it's exactly the same. It's about
mapping an "oauth scope" to a group of protocol mappers, roles and "role
scopes".
Fits perfectly IMO ;)
On 28 September 2017 at 15:38, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
Although unifying all of this is probably very elegant from a code
perspective, I agree with Pedro. For me scopes and roles are two different
concepts. Scopes being mainly for the external client/user view. Especially
when you look into the direction of GDPR or UMA 2.0 client scopes, they
could be a means to describe privacy-relevant information (e.g. what kind
of data, the purpose of accessing it, associated descriptions). Latest at
that point, still calling this role and managing it the same way as roles
will probably be very confusing...
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
Dr.-Ing. Rainer Kallenbach, Michael Hahn
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@
lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Donnerstag, 28. September 2017 14:53
To: Thorgersen, Stian <stian(a)redhat.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] rename client templates to scope?
I think all these concepts under a single umbrella is confusing.
Regarding roles and scopes ....
IMO, roles and scopes are separated things. It would be nice if we had a
specific area for Scope Mapping, where from there I could create scopes and
manage their configuration (consent, param required, etc), associate scopes
with roles (and not turn roles into scopes) and associate mappers with
scopes.
And also push scopes into a separated claim within tokens.
On Thu, Sep 28, 2017 at 4:35 AM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> Interesting. So client templates could become a very flexible thing
> that covers many uses. So one single concept could cover:
>
> * Templates as today
> * Scope
> * Namespaces
>
> I like the idea, but the devil is in the details. How would it end up
> looking. Would it be easy to use.
>
> On 27 September 2017 at 19:38, Bill Burke <bburke(a)redhat.com> wrote:
>
> > Maybe want to allow client scopes to define their own roles too.
> > Then we have a role namespace as well. Could even think about
> > removing realm roles if we do this.
> >
> > On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen
> > <sthorger(a)redhat.com>
> > wrote:
> > > Interesting idea. That might just work and be a nice and easy way
> > > to
> add
> > > proper support for OAuth/OIDC scope.
> > >
> > > On 25 September 2017 at 17:11, Bill Burke <bburke(a)redhat.com>
wrote:
> > >>
> > >> This is something for 4.0
> > >>
> > >> Was thinking that we should rename Client Templates to Client
Scopes.
> > >> For oauth, oidc, and token exchange client asks for a specific
> > >> scope with the "scope" parameter. This "scope"
parameter would
> > >> be the name of a client-id or a client scope (formerly client
> > >> emplates. Clients will be granted access to scopes in the admin
> > >> console. Probably through authz services.
> > >>
> > >>
> > >>
> > >> --
> > >> Bill Burke
> > >> Red Hat
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > >
> >
> >
> >
> > --
> > Bill Burke
> > Red Hat
> >
> _______________________________________________
> 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
3:43 p.m.
Current client templates do map nicely to OAuth scopes. Where I was
unsure was them additionally having a role namespace too.
Our consent screen logic is a mess. We loop through every protocol
mapper and role stuffed in the token to blurt out a message on the
consent screen for each. Its messy, ugly, and not very easy to make
it look like you want. If we have Client Scopes, then clients can
consolidate mappers and roles into a consent message that covers them
all.
So community? Anybody interested in implementing? The tough part
will be to finally get support for OAuth scopes and also to make sure
that all this is backward compatible with Client Templates (migration
scripts if needed).
On Fri, Sep 29, 2017 at 3:12 AM, Stian Thorgersen <sthorger(a)redhat.com> wrote:
The term "scope" has two meanings within Keycloak.
That's confusing.
Firstly scope means a "client is allowed to get this role", but then
there's the other meaning coming from OAuth which means "client is
requesting access to this set of resources". So let's call them "roles
scope" for the first and "oauth scope" for the second in this mail to
remove confusion around that.
With regards to Bill's suggestion I don't find it confusing at all. A
"client template" is really only a grouping mechanism for protocol mappers,
roles and "role scopes". It's currently only used to allow clients to
share
this config, but if you think about what properly introducing "oauth
scopes" properly would mean to Keycloak it's exactly the same. It's about
mapping an "oauth scope" to a group of protocol mappers, roles and "role
scopes".
Fits perfectly IMO ;)
On 28 September 2017 at 15:38, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
> Although unifying all of this is probably very elegant from a code
> perspective, I agree with Pedro. For me scopes and roles are two different
> concepts. Scopes being mainly for the external client/user view. Especially
> when you look into the direction of GDPR or UMA 2.0 client scopes, they
> could be a means to describe privacy-relevant information (e.g. what kind
> of data, the purpose of accessing it, associated descriptions). Latest at
> that point, still calling this role and managing it the same way as roles
> will probably be very confusing...
>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster(a)bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
> Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
> -----Original Message-----
> From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@
> lists.jboss.org] On Behalf Of Pedro Igor Silva
> Sent: Donnerstag, 28. September 2017 14:53
> To: Thorgersen, Stian <stian(a)redhat.com>
> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> Subject: Re: [keycloak-dev] rename client templates to scope?
>
> I think all these concepts under a single umbrella is confusing.
>
> Regarding roles and scopes ....
>
> IMO, roles and scopes are separated things. It would be nice if we had a
> specific area for Scope Mapping, where from there I could create scopes and
> manage their configuration (consent, param required, etc), associate scopes
> with roles (and not turn roles into scopes) and associate mappers with
> scopes.
>
> And also push scopes into a separated claim within tokens.
>
>
> On Thu, Sep 28, 2017 at 4:35 AM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
> > Interesting. So client templates could become a very flexible thing
> > that covers many uses. So one single concept could cover:
> >
> > * Templates as today
> > * Scope
> > * Namespaces
> >
> > I like the idea, but the devil is in the details. How would it end up
> > looking. Would it be easy to use.
> >
> > On 27 September 2017 at 19:38, Bill Burke <bburke(a)redhat.com> wrote:
> >
> > > Maybe want to allow client scopes to define their own roles too.
> > > Then we have a role namespace as well. Could even think about
> > > removing realm roles if we do this.
> > >
> > > On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen
> > > <sthorger(a)redhat.com>
> > > wrote:
> > > > Interesting idea. That might just work and be a nice and easy way
> > > > to
> > add
> > > > proper support for OAuth/OIDC scope.
> > > >
> > > > On 25 September 2017 at 17:11, Bill Burke <bburke(a)redhat.com>
wrote:
> > > >>
> > > >> This is something for 4.0
> > > >>
> > > >> Was thinking that we should rename Client Templates to Client
> Scopes.
> > > >> For oauth, oidc, and token exchange client asks for a specific
> > > >> scope with the "scope" parameter. This
"scope" parameter would
> > > >> be the name of a client-id or a client scope (formerly client
> > > >> emplates. Clients will be granted access to scopes in the admin
> > > >> console. Probably through authz services.
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Bill Burke
> > > >> Red Hat
> > > >> _______________________________________________
> > > >> keycloak-dev mailing list
> > > >> keycloak-dev(a)lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Bill Burke
> > > Red Hat
> > >
> > _______________________________________________
> > 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
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
Red Hat
2654
days inactive
2658
days old
7 comments
4 participants
participants (4)
-
Bill Burke -
Pedro Igor Silva -
Schuster Sebastian (INST/ESY1) -
Stian Thorgersen