2:46 a.m.
Hi,
I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for
the first iteration of client scopes. I will talk on tomorrow call about
the details and still need to write some more automated tests. But I am
seing PR now if someone wants to take a look.
Summary:
- Client Templates were renamed to "Client Scopes". Some things were
removed from the client template admin console (EG. Theme setting added
recently). Also I've removed some ClientTemplate model properties, which
were never used. Client Scope still has list of protocol mappers and
list of "Scopes" (Roles scope mappings).
- There is new tab "Client Scopes" on client. Here you can assign client
scopes to client. Each client has 2 types of client scopes:
-- Default client scopes -- Those client scopes are automatically
applied when login with the client. Their protocol mappers and "Role
scope mappings" are always used.
-- Optional client scopes -- Those client scopes are applicable just for
OIDC clients. They are used just if they are requested by "scope"
parameter during login
- Under "Client scopes", there is new tab "Default Client Scopes" .
This
allows to specify "Realm default client scopes" and "Realm optional
client scopes". The scopes configured here will be added as
default/optional scopes to new clients. Client can override this (Remove
those defaults and add some different client scopes). So it works
similarly to Default Roles.
- Roles don't have "Scope Param Required" flag anymore. Protocol mappers
don't have "Consent required" and "Consent text" anymore. Client
scopes
don't have "Full scope allowed" flag. But clients still have "Full
scope
allowed" flag for now and it's still ON by default for newly created
clients.
- There are few builtin client scopes added to each realm. There are 4
claims scopes defined in OIDC specification and those are added by
default: "profile", "email", "address" and "phone"
with the protocol
mappers corresponding to the claims described in OIDC specification [1].
-- The "profile" and "email" are configured as default scopes and
hence
are automatically added to new clients.
-- The "phone" and "address" are configured as optional scopes by
default.
-- The clients now doesn't have any protocolMappers added by default
when they are created. I've added "profile" and "email" as default
scopes due it's most close to the previous default protocolMappers we had.
- For SAML, there is "role_list" default client scope, containing just 1
protocol mapper "role list". So both OIDC and SAML clients don't have
any protocol mappers by default, it's driven by client scopes now by
default.
- There is "offline_access" OIDC client scope, which is optional scope
by default. This scope contains just "offline_access" realm role. Due
the fact, that parameter "Scope Param Required" was removed from
RoleModel, the "offline_access" role is now automatically available in
tokens for clients with "Full Scope Allowed", even if no offline tokens
was requsted. But I don't think it's big issue besides a bit bigger
token. Same also already applies for uma_authorization and some other
built-in roles. The fact, that offline token is requested is now driven
by "offline_access" scope. But user should still have "offline_access"
role to be able to receive offline token.
Consent changes:
- Consent screen now doesn't display protocolMappers (claims) and roles,
but instead it displays just client scopes. So by default, the consent
screen contains 2 items "User profile" and "Email address", which
correspond to the "profile" and "email" OIDC scopes.
- There can be still the case, when client has some protocolMappers or
role scope mappings defined on itself. So I've added flag "Display On
Consent Screen" on clients (It's OFF by default) to specify if some
message should be shown on consent screen about claims dedicated
directly to client itself. It's useful especially when client doesn't
have any client scopes as the consent screen wouldn't be displayed in
that case.
- During this refactoring, I've tried to do some cleanup we discussed
before, so I've removed protocolMappers and roles from clientSession.
Instead I've added clientScopes to refresh token. During refreshing
token, it's checked that user still has all the consents, which are in
the refresh token. So in case that user revoked consents in the
meantime, the token refresh will fail. ProtocolMappers and scoped roles
are always re-computed from the clientScopes. So if for example another
claim was added to scope "profile", it will automatically be applied
after refreshed token. I don't see an issue with that. User approved on
consent screen scope "profile" and he may not be concerned what
claims/scoped roles are in profile.
- Migration: In the end I did not change existing clients and did not
remove protocolMappers from them and didn't add default/optional client
scopes to them. The only exception is "offline_access" profile, which is
added as optional to all clients, which had scope to "offline_access"
role. Consents are not migrated - again with the only exception being
"offline_access" consent, so refreshing offline tokens from previous
version still works. The new consent screen is something quite different
than previous one, so makes sense to show it to users again when they
want to login, even if they approved protocolMappers for the previous
version.
Sorry for long email and long PR :) More tomorrow...
[1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
Marek
9:13 p.m.
Is the long-term goal to make the "Scopes" tab for clients go away? Because
currently it's a bit confusing both are there...
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. Stefan Ferber,
Michael Hahn
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org]
On Behalf Of Marek Posolda
Sent: Mittwoch, 14. März 2018 18:47
To: keycloak-dev(a)lists.jboss.org
Subject: [keycloak-dev] Initial client scopes PR
Hi,
I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for the first
iteration of client scopes. I will talk on tomorrow call about the details and still need
to write some more automated tests. But I am seing PR now if someone wants to take a
look.
Summary:
- Client Templates were renamed to "Client Scopes". Some things were removed
from the client template admin console (EG. Theme setting added recently). Also I've
removed some ClientTemplate model properties, which were never used. Client Scope still
has list of protocol mappers and list of "Scopes" (Roles scope mappings).
- There is new tab "Client Scopes" on client. Here you can assign client scopes
to client. Each client has 2 types of client scopes:
-- Default client scopes -- Those client scopes are automatically applied when login with
the client. Their protocol mappers and "Role scope mappings" are always used.
-- Optional client scopes -- Those client scopes are applicable just for OIDC clients.
They are used just if they are requested by "scope"
parameter during login
- Under "Client scopes", there is new tab "Default Client Scopes" .
This allows to specify "Realm default client scopes" and "Realm optional
client scopes". The scopes configured here will be added as default/optional scopes
to new clients. Client can override this (Remove those defaults and add some different
client scopes). So it works similarly to Default Roles.
- Roles don't have "Scope Param Required" flag anymore. Protocol mappers
don't have "Consent required" and "Consent text" anymore. Client
scopes don't have "Full scope allowed" flag. But clients still have
"Full scope allowed" flag for now and it's still ON by default for newly
created clients.
- There are few builtin client scopes added to each realm. There are 4 claims scopes
defined in OIDC specification and those are added by
default: "profile", "email", "address" and "phone"
with the protocol mappers corresponding to the claims described in OIDC specification
[1].
-- The "profile" and "email" are configured as default scopes and
hence are automatically added to new clients.
-- The "phone" and "address" are configured as optional scopes by
default.
-- The clients now doesn't have any protocolMappers added by default when they are
created. I've added "profile" and "email" as default scopes due
it's most close to the previous default protocolMappers we had.
- For SAML, there is "role_list" default client scope, containing just 1
protocol mapper "role list". So both OIDC and SAML clients don't have any
protocol mappers by default, it's driven by client scopes now by default.
- There is "offline_access" OIDC client scope, which is optional scope by
default. This scope contains just "offline_access" realm role. Due the fact,
that parameter "Scope Param Required" was removed from RoleModel, the
"offline_access" role is now automatically available in tokens for clients with
"Full Scope Allowed", even if no offline tokens was requsted. But I don't
think it's big issue besides a bit bigger token. Same also already applies for
uma_authorization and some other built-in roles. The fact, that offline token is requested
is now driven by "offline_access" scope. But user should still have
"offline_access"
role to be able to receive offline token.
Consent changes:
- Consent screen now doesn't display protocolMappers (claims) and roles, but instead
it displays just client scopes. So by default, the consent screen contains 2 items
"User profile" and "Email address", which correspond to the
"profile" and "email" OIDC scopes.
- There can be still the case, when client has some protocolMappers or role scope mappings
defined on itself. So I've added flag "Display On Consent Screen" on clients
(It's OFF by default) to specify if some message should be shown on consent screen
about claims dedicated directly to client itself. It's useful especially when client
doesn't have any client scopes as the consent screen wouldn't be displayed in that
case.
- During this refactoring, I've tried to do some cleanup we discussed before, so
I've removed protocolMappers and roles from clientSession.
Instead I've added clientScopes to refresh token. During refreshing token, it's
checked that user still has all the consents, which are in the refresh token. So in case
that user revoked consents in the meantime, the token refresh will fail. ProtocolMappers
and scoped roles are always re-computed from the clientScopes. So if for example another
claim was added to scope "profile", it will automatically be applied after
refreshed token. I don't see an issue with that. User approved on consent screen scope
"profile" and he may not be concerned what claims/scoped roles are in profile.
- Migration: In the end I did not change existing clients and did not remove
protocolMappers from them and didn't add default/optional client scopes to them. The
only exception is "offline_access" profile, which is added as optional to all
clients, which had scope to "offline_access"
role. Consents are not migrated - again with the only exception being
"offline_access" consent, so refreshing offline tokens from previous version
still works. The new consent screen is something quite different than previous one, so
makes sense to show it to users again when they want to login, even if they approved
protocolMappers for the previous version.
Sorry for long email and long PR :) More tomorrow...
[1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:48 p.m.
It's not yet clear... Maybe we can rename tab to "Role Scopes"? Will it
be clearer or even more confusing? :)
Marek
On 15/03/18 13:13, Schuster Sebastian (INST/ESY1) wrote:
Is the long-term goal to make the "Scopes" tab for clients
go away? Because currently it's a bit confusing both are there...
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. Stefan Ferber,
Michael Hahn
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org]
On Behalf Of Marek Posolda
Sent: Mittwoch, 14. März 2018 18:47
To: keycloak-dev(a)lists.jboss.org
Subject: [keycloak-dev] Initial client scopes PR
Hi,
I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for the first
iteration of client scopes. I will talk on tomorrow call about the details and still need
to write some more automated tests. But I am seing PR now if someone wants to take a
look.
Summary:
- Client Templates were renamed to "Client Scopes". Some things were removed
from the client template admin console (EG. Theme setting added recently). Also I've
removed some ClientTemplate model properties, which were never used. Client Scope still
has list of protocol mappers and list of "Scopes" (Roles scope mappings).
- There is new tab "Client Scopes" on client. Here you can assign client scopes
to client. Each client has 2 types of client scopes:
-- Default client scopes -- Those client scopes are automatically applied when login with
the client. Their protocol mappers and "Role scope mappings" are always used.
-- Optional client scopes -- Those client scopes are applicable just for OIDC clients.
They are used just if they are requested by "scope"
parameter during login
- Under "Client scopes", there is new tab "Default Client Scopes" .
This allows to specify "Realm default client scopes" and "Realm optional
client scopes". The scopes configured here will be added as default/optional scopes
to new clients. Client can override this (Remove those defaults and add some different
client scopes). So it works similarly to Default Roles.
- Roles don't have "Scope Param Required" flag anymore. Protocol mappers
don't have "Consent required" and "Consent text" anymore. Client
scopes don't have "Full scope allowed" flag. But clients still have
"Full scope allowed" flag for now and it's still ON by default for newly
created clients.
- There are few builtin client scopes added to each realm. There are 4 claims scopes
defined in OIDC specification and those are added by
default: "profile", "email", "address" and
"phone" with the protocol mappers corresponding to the claims described in OIDC
specification [1].
-- The "profile" and "email" are configured as default scopes and
hence are automatically added to new clients.
-- The "phone" and "address" are configured as optional scopes by
default.
-- The clients now doesn't have any protocolMappers added by default when they are
created. I've added "profile" and "email" as default scopes due
it's most close to the previous default protocolMappers we had.
- For SAML, there is "role_list" default client scope, containing just 1
protocol mapper "role list". So both OIDC and SAML clients don't have any
protocol mappers by default, it's driven by client scopes now by default.
- There is "offline_access" OIDC client scope, which is optional scope by
default. This scope contains just "offline_access" realm role. Due the fact,
that parameter "Scope Param Required" was removed from RoleModel, the
"offline_access" role is now automatically available in tokens for clients with
"Full Scope Allowed", even if no offline tokens was requsted. But I don't
think it's big issue besides a bit bigger token. Same also already applies for
uma_authorization and some other built-in roles. The fact, that offline token is requested
is now driven by "offline_access" scope. But user should still have
"offline_access"
role to be able to receive offline token.
Consent changes:
- Consent screen now doesn't display protocolMappers (claims) and roles, but instead
it displays just client scopes. So by default, the consent screen contains 2 items
"User profile" and "Email address", which correspond to the
"profile" and "email" OIDC scopes.
- There can be still the case, when client has some protocolMappers or role scope
mappings defined on itself. So I've added flag "Display On Consent Screen"
on clients (It's OFF by default) to specify if some message should be shown on consent
screen about claims dedicated directly to client itself. It's useful especially when
client doesn't have any client scopes as the consent screen wouldn't be displayed
in that case.
- During this refactoring, I've tried to do some cleanup we discussed before, so
I've removed protocolMappers and roles from clientSession.
Instead I've added clientScopes to refresh token. During refreshing token, it's
checked that user still has all the consents, which are in the refresh token. So in case
that user revoked consents in the meantime, the token refresh will fail. ProtocolMappers
and scoped roles are always re-computed from the clientScopes. So if for example another
claim was added to scope "profile", it will automatically be applied after
refreshed token. I don't see an issue with that. User approved on consent screen scope
"profile" and he may not be concerned what claims/scoped roles are in profile.
- Migration: In the end I did not change existing clients and did not remove
protocolMappers from them and didn't add default/optional client scopes to them. The
only exception is "offline_access" profile, which is added as optional to all
clients, which had scope to "offline_access"
role. Consents are not migrated - again with the only exception being
"offline_access" consent, so refreshing offline tokens from previous version
still works. The new consent screen is something quite different than previous one, so
makes sense to show it to users again when they want to login, even if they approved
protocolMappers for the previous version.
Sorry for long email and long PR :) More tomorrow...
[1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:15 p.m.
Doesn't the current client scope functionality cover everything that was possible on
the scopes tab, except for the ability to simply allow all scopes for a client?
Then my proposal would be to add that functionality to the "client scope" tab
and call it "scope" tab again, and maybe rename the menu on the left to
"scope mappings"
or also just "scopes".
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. Stefan Ferber,
Michael Hahn
-----Original Message-----
From: Marek Posolda [mailto:mposolda@redhat.com]
Sent: Freitag, 16. März 2018 08:48
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] Initial client scopes PR
It's not yet clear... Maybe we can rename tab to "Role Scopes"? Will it be
clearer or even more confusing? :)
Marek
On 15/03/18 13:13, Schuster Sebastian (INST/ESY1) wrote:
Is the long-term goal to make the "Scopes" tab for clients
go away? Because currently it's a bit confusing both are there...
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. Stefan Ferber, Michael Hahn
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org
[mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Marek
Posolda
Sent: Mittwoch, 14. März 2018 18:47
To: keycloak-dev(a)lists.jboss.org
Subject: [keycloak-dev] Initial client scopes PR
Hi,
I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for the first
iteration of client scopes. I will talk on tomorrow call about the details and still need
to write some more automated tests. But I am seing PR now if someone wants to take a
look.
Summary:
- Client Templates were renamed to "Client Scopes". Some things were removed
from the client template admin console (EG. Theme setting added recently). Also I've
removed some ClientTemplate model properties, which were never used. Client Scope still
has list of protocol mappers and list of "Scopes" (Roles scope mappings).
- There is new tab "Client Scopes" on client. Here you can assign client scopes
to client. Each client has 2 types of client scopes:
-- Default client scopes -- Those client scopes are automatically applied when login with
the client. Their protocol mappers and "Role scope mappings" are always used.
-- Optional client scopes -- Those client scopes are applicable just for OIDC clients.
They are used just if they are requested by "scope"
parameter during login
- Under "Client scopes", there is new tab "Default Client Scopes" .
This allows to specify "Realm default client scopes" and "Realm optional
client scopes". The scopes configured here will be added as default/optional scopes
to new clients. Client can override this (Remove those defaults and add some different
client scopes). So it works similarly to Default Roles.
- Roles don't have "Scope Param Required" flag anymore. Protocol mappers
don't have "Consent required" and "Consent text" anymore. Client
scopes don't have "Full scope allowed" flag. But clients still have
"Full scope allowed" flag for now and it's still ON by default for newly
created clients.
- There are few builtin client scopes added to each realm. There are 4
claims scopes defined in OIDC specification and those are added by
default: "profile", "email", "address" and
"phone" with the protocol mappers corresponding to the claims described in OIDC
specification [1].
-- The "profile" and "email" are configured as default scopes and
hence are automatically added to new clients.
-- The "phone" and "address" are configured as optional scopes by
default.
-- The clients now doesn't have any protocolMappers added by default when they are
created. I've added "profile" and "email" as default scopes due
it's most close to the previous default protocolMappers we had.
- For SAML, there is "role_list" default client scope, containing just 1
protocol mapper "role list". So both OIDC and SAML clients don't have any
protocol mappers by default, it's driven by client scopes now by default.
- There is "offline_access" OIDC client scope, which is optional scope by
default. This scope contains just "offline_access" realm role. Due the fact,
that parameter "Scope Param Required" was removed from RoleModel, the
"offline_access" role is now automatically available in tokens for clients with
"Full Scope Allowed", even if no offline tokens was requsted. But I don't
think it's big issue besides a bit bigger token. Same also already applies for
uma_authorization and some other built-in roles. The fact, that offline token is requested
is now driven by "offline_access" scope. But user should still have
"offline_access"
role to be able to receive offline token.
Consent changes:
- Consent screen now doesn't display protocolMappers (claims) and roles, but instead
it displays just client scopes. So by default, the consent screen contains 2 items
"User profile" and "Email address", which correspond to the
"profile" and "email" OIDC scopes.
- There can be still the case, when client has some protocolMappers or role scope
mappings defined on itself. So I've added flag "Display On Consent Screen"
on clients (It's OFF by default) to specify if some message should be shown on consent
screen about claims dedicated directly to client itself. It's useful especially when
client doesn't have any client scopes as the consent screen wouldn't be displayed
in that case.
- During this refactoring, I've tried to do some cleanup we discussed before, so
I've removed protocolMappers and roles from clientSession.
Instead I've added clientScopes to refresh token. During refreshing token, it's
checked that user still has all the consents, which are in the refresh token. So in case
that user revoked consents in the meantime, the token refresh will fail. ProtocolMappers
and scoped roles are always re-computed from the clientScopes. So if for example another
claim was added to scope "profile", it will automatically be applied after
refreshed token. I don't see an issue with that. User approved on consent screen scope
"profile" and he may not be concerned what claims/scoped roles are in profile.
- Migration: In the end I did not change existing clients and did not remove
protocolMappers from them and didn't add default/optional client scopes to them. The
only exception is "offline_access" profile, which is added as optional to all
clients, which had scope to "offline_access"
role. Consents are not migrated - again with the only exception being
"offline_access" consent, so refreshing offline tokens from previous version
still works. The new consent screen is something quite different than previous one, so
makes sense to show it to users again when they want to login, even if they approved
protocolMappers for the previous version.
Sorry for long email and long PR :) More tomorrow...
[1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:19 p.m.
On 16/03/18 09:15, Schuster Sebastian (INST/ESY1) wrote:
Doesn't the current client scope functionality cover everything
that was possible on the scopes tab, except for the ability to simply allow all scopes for
a client?
Not sure what you mean. I am probably lost in what "scope" you
are
talking about :) Client scope (new thing, which is not yet in Keycloak
master) or "Role scope mappings" (functionality which is under
"Scopes"
tab of client or clientTemplate in current master?)
But at least for now with my PR applied, clients still have "Scope" tab
on themselves as it's still possible to grant "Role scope mappings"
directly to client. But clients will also inherit "Role scope mappings"
from all client scopes, which are assigned to them.
Marek
Then my proposal would be to add that functionality to the
"client scope" tab and call it "scope" tab again, and maybe rename the
menu on the left to "scope mappings"
or also just "scopes".
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. Stefan Ferber,
Michael Hahn
-----Original Message-----
From: Marek Posolda [mailto:mposolda@redhat.com]
Sent: Freitag, 16. März 2018 08:48
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] Initial client scopes PR
It's not yet clear... Maybe we can rename tab to "Role Scopes"? Will it be
clearer or even more confusing? :)
Marek
On 15/03/18 13:13, Schuster Sebastian (INST/ESY1) wrote:
> Is the long-term goal to make the "Scopes" tab for clients go away? Because
currently it's a bit confusing both are there...
>
> 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. Stefan Ferber, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: keycloak-dev-bounces(a)lists.jboss.org
> [mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Marek
> Posolda
> Sent: Mittwoch, 14. März 2018 18:47
> To: keycloak-dev(a)lists.jboss.org
> Subject: [keycloak-dev] Initial client scopes PR
>
> Hi,
>
> I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for the first
iteration of client scopes. I will talk on tomorrow call about the details and still need
to write some more automated tests. But I am seing PR now if someone wants to take a
look.
>
> Summary:
>
> - Client Templates were renamed to "Client Scopes". Some things were
removed from the client template admin console (EG. Theme setting added recently). Also
I've removed some ClientTemplate model properties, which were never used. Client Scope
still has list of protocol mappers and list of "Scopes" (Roles scope mappings).
>
>
> - There is new tab "Client Scopes" on client. Here you can assign client
scopes to client. Each client has 2 types of client scopes:
> -- Default client scopes -- Those client scopes are automatically applied when login
with the client. Their protocol mappers and "Role scope mappings" are always
used.
> -- Optional client scopes -- Those client scopes are applicable just for OIDC
clients. They are used just if they are requested by "scope"
> parameter during login
>
>
> - Under "Client scopes", there is new tab "Default Client Scopes"
. This allows to specify "Realm default client scopes" and "Realm optional
client scopes". The scopes configured here will be added as default/optional scopes
to new clients. Client can override this (Remove those defaults and add some different
client scopes). So it works similarly to Default Roles.
>
>
> - Roles don't have "Scope Param Required" flag anymore. Protocol
mappers don't have "Consent required" and "Consent text" anymore.
Client scopes don't have "Full scope allowed" flag. But clients still have
"Full scope allowed" flag for now and it's still ON by default for newly
created clients.
>
> - There are few builtin client scopes added to each realm. There are 4
> claims scopes defined in OIDC specification and those are added by
> default: "profile", "email", "address" and
"phone" with the protocol mappers corresponding to the claims described in OIDC
specification [1].
> -- The "profile" and "email" are configured as default scopes and
hence are automatically added to new clients.
> -- The "phone" and "address" are configured as optional scopes by
default.
> -- The clients now doesn't have any protocolMappers added by default when they
are created. I've added "profile" and "email" as default scopes
due it's most close to the previous default protocolMappers we had.
>
> - For SAML, there is "role_list" default client scope, containing just 1
protocol mapper "role list". So both OIDC and SAML clients don't have any
protocol mappers by default, it's driven by client scopes now by default.
>
> - There is "offline_access" OIDC client scope, which is optional scope by
default. This scope contains just "offline_access" realm role. Due the fact,
that parameter "Scope Param Required" was removed from RoleModel, the
"offline_access" role is now automatically available in tokens for clients with
"Full Scope Allowed", even if no offline tokens was requsted. But I don't
think it's big issue besides a bit bigger token. Same also already applies for
uma_authorization and some other built-in roles. The fact, that offline token is requested
is now driven by "offline_access" scope. But user should still have
"offline_access"
> role to be able to receive offline token.
>
> Consent changes:
> - Consent screen now doesn't display protocolMappers (claims) and roles, but
instead it displays just client scopes. So by default, the consent screen contains 2 items
"User profile" and "Email address", which correspond to the
"profile" and "email" OIDC scopes.
>
> - There can be still the case, when client has some protocolMappers or role scope
mappings defined on itself. So I've added flag "Display On Consent Screen"
on clients (It's OFF by default) to specify if some message should be shown on consent
screen about claims dedicated directly to client itself. It's useful especially when
client doesn't have any client scopes as the consent screen wouldn't be displayed
in that case.
>
> - During this refactoring, I've tried to do some cleanup we discussed before, so
I've removed protocolMappers and roles from clientSession.
> Instead I've added clientScopes to refresh token. During refreshing token,
it's checked that user still has all the consents, which are in the refresh token. So
in case that user revoked consents in the meantime, the token refresh will fail.
ProtocolMappers and scoped roles are always re-computed from the clientScopes. So if for
example another claim was added to scope "profile", it will automatically be
applied after refreshed token. I don't see an issue with that. User approved on
consent screen scope "profile" and he may not be concerned what claims/scoped
roles are in profile.
>
> - Migration: In the end I did not change existing clients and did not remove
protocolMappers from them and didn't add default/optional client scopes to them. The
only exception is "offline_access" profile, which is added as optional to all
clients, which had scope to "offline_access"
> role. Consents are not migrated - again with the only exception being
"offline_access" consent, so refreshing offline tokens from previous version
still works. The new consent screen is something quite different than previous one, so
makes sense to show it to users again when they want to login, even if they approved
protocolMappers for the previous version.
>
> Sorry for long email and long PR :) More tomorrow...
>
>
> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
2244
days inactive
2246
days old
4 comments
2 participants
participants (2)
-
Marek Posolda -
Schuster Sebastian (INST/ESY1)