3:56 p.m.
It seems that for OIDC certification, we will need more proper support
for "scope" parameter. There are few tests from OIDC conformance
testsuite, which end with WARNING because of issues with "scope" parameter.
SUMMARY OF SPECS REQUIREMENTS
-----------------------------
- In OIDC specification, the "scope" parameter is actually REQUIRED. And
you must add the scope value "openid" to all authorization requests.
Hence if you don't use "scope=openid", the request is pure OAuth2
request, but it's not OIDC request.
In https://issues.jboss.org/browse/KEYCLOAK-3147 we discuss the
possibility that we should change our adapters and add "scope=openid" to
all requests, and also the possibility to remove IDToken if it's not
OIDC request (and maybe other things). However it may be potential issue
with backward compatibility with older adapters (which don't add
"scope=openid" at all).
- OIDC also prescribes the "scope=offline_access", which you use if you
want offline token. We actually support this as we have realm role
"offline_access", with scopeParamRequired=true . So this role is applied
just if it's included in scope parameter. This is our only support of
scope param actually. ATM we reference the realm roles by name (role
name must match the value of scope parameter) and clientRoles by
"clientId/roleName" . So it's not very flexible and won't work well in
the future with role namespaces.
- OIDC defines four other scope values, which we don't support, with the
meaning like this:
profile
OPTIONAL. This scope value requests access to the End-User's
default profile Claims, which are: "name", "family_name",
"given_name",
"middle_name", "nickname", "preferred_username",
"profile", "picture",
"website", "gender", "birthdate", "zoneinfo",
"locale", and "updated_at".
email
OPTIONAL. This scope value requests access to the "email" and
"email_verified" Claims.
address
OPTIONAL. This scope value requests access to the "address" Claim.
phone
OPTIONAL. This scope value requests access to the "phone_number"
and "phone_number_verified" Claims.
- Not directly related to scopes, however OIDC also has one parameter
"claims" described in section
http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter .
This allows to define some additional claims, which should be included
in IDToken or UserInfo endpoint in addition to claims specified by
"scope" parameter.
HOW TO IMPLEMENT?
-----------------
My current thinking is, that we will have 2 kinds of protocolMappers and
roles.
1) "Always applied" - Those roles/protocolMappers are always applied to
token even if they are not specified by scope parameter.
2) "Applied on demand" - Those roles/protocolMappers are applied just if
they are specifically requested by scope parameter
For roles, we already have that with "scope param required" flag defined
per roleModel. However for protocolMappers we don't have it yet.
IMO We will also need some more flexible way to specify how the value of
scope parameter will be mapped to roles and protocolMappers. For example
if I use "scope=foo", it can mean that I want realm role "foo1",
client
role "client1/foo2" and protocolMapper for "firstName" and
"lastName" etc.
I can see 2 possibilities:
a) Configure allowed scope param separately per each role / protocolMapper
If some role has "Scope param required" checked, you will have
possibility to configure list of available values of scope parameter,
which this role will be applied to. This will be configured per-each
role separately.
Example: I have realm role "foo" . I check "scope param required" to
true. Then I will define "scope param values" : "bar" and
"baz". It
means that if someone uses parameter "scope=bar" or
scope=baz", then role "foo" will be applied to token. Otherwise it
won't
be applied.
Similarly it will be for protocolMappers. We will add switch "Scope
param required" to protocolMappers and we will use list of available
values of scope parameter, which is configured per each protocolMapper
separately.
b) Configure scope parameter in separate place
We will have another tab "Scope parameter config" (or maybe rather
another sub-tab under existing "Scope" tab). Here you will define the
allowed values of scope parameter. For each allowed value, you will
define protocolMappers and roles to apply. Hence for example for
"profile" scope parameter, you will define all protocolMappers for
corresponding claims ( name, family_name, ...) here.
We will still need "scope param required" switch for protocolMappers in
case (b).
My current thinking is to go with (a). So when you go to some role (or
protocolMapper) in admin console you will see if you need scope
parameter and what are available values of scope parameter to request it.
WDYT? Another ideas?
Marek
9:42 p.m.
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Thursday, June 30, 2016 10:56:04 AM
Subject: [keycloak-dev] Scope parameter support
IMO We will also need some more flexible way to specify how the value of
scope parameter will be mapped to roles and protocolMappers. For example
if I use "scope=foo", it can mean that I want realm role "foo1",
client
role "client1/foo2" and protocolMapper for "firstName" and
"lastName" etc.
+1. I think I have mentioned something like that on a previous thread, where we should be
able to build scopes from attributes (eg.: from user) or even compose a scope based on
multiple attributes. The same concept applies to protocol mappers, just like you
proposed.
I can see 2 possibilities:
a) Configure allowed scope param separately per each role / protocolMapper
If some role has "Scope param required" checked, you will have
possibility to configure list of available values of scope parameter,
which this role will be applied to. This will be configured per-each
role separately.
Example: I have realm role "foo" . I check "scope param required" to
true. Then I will define "scope param values" : "bar" and
"baz". It
means that if someone uses parameter "scope=bar" or
scope=baz", then role "foo" will be applied to token. Otherwise it
won't
be applied.
Similarly it will be for protocolMappers. We will add switch "Scope
param required" to protocolMappers and we will use list of available
values of scope parameter, which is configured per each protocolMapper
separately.
IMO, roles and scopes are separated concepts. Where scopes may also implicate access to
the roles granted to an user. Scopes have a pretty broad meaning.
With that in mind, don't you think that we could just have a scope "roles" ?
Which could be used to ask for the roles associated with the user that the client is
acting on behalf of ?
I think that the Protocol Mappers (for OIDC) provide pretty much everything you need. The
missing part would be to make it capable of grouping other mappers. Actually, the concept
behind a protocol mapper is pretty much
related with a scope.
11:29 p.m.
On 06/30/2016 03:42 PM, Pedro Igor Silva wrote:
IMO, roles and scopes are separated concepts. Where scopes may also
implicate access to the roles granted to an user. Scopes have a
pretty broad meaning.
With that in mind, don't you think that we could just have a scope
"roles" ? Which could be used to ask for the roles associated with
the user that the client is acting on behalf of ?
I think that the Protocol Mappers (for OIDC) provide pretty much
everything you need. The missing part would be to make it capable of
grouping other mappers. Actually, the concept behind a protocol
mapper is pretty much related with a scope.
I think it would be valuable for the Keycloak team to define and publish
what it thinks the terms "scope" and "role" mean and how those values
propagate through Keycloak (e.g. where do they come from, if they are
synthesized from other values then how). As well as their intended use.
People may be coming to Keycloak with a different set of assumptions on
what those terms mean.
At the same time it would be worthwhile to include a discussion of
groups and how they relate to roles (and scope?). That is because many
applications define and manage roles themselves and assign roles based
on group attributes returned in an assertion/claim attribute. Typically
we have not expected an IdP to assign roles to a user. In an application
which supports multiple IdP's (other than Keycloak, e.g. federation) you
simply cannot assume the IdP can map a user into a role. Mapping a user
into a role is usually application specific logic synthesized from
attributes bound to the user principal.
--
John
2:47 a.m.
----- Original Message -----
From: "John Dennis" <jdennis(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>, "Marek Posolda"
<mposolda(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Thursday, June 30, 2016 6:29:01 PM
Subject: Re: [keycloak-dev] Scope parameter support
On 06/30/2016 03:42 PM, Pedro Igor Silva wrote:
> IMO, roles and scopes are separated concepts. Where scopes may also
> implicate access to the roles granted to an user. Scopes have a
> pretty broad meaning.
>
> With that in mind, don't you think that we could just have a scope
> "roles" ? Which could be used to ask for the roles associated with
> the user that the client is acting on behalf of ?
>
> I think that the Protocol Mappers (for OIDC) provide pretty much
> everything you need. The missing part would be to make it capable of
> grouping other mappers. Actually, the concept behind a protocol
> mapper is pretty much related with a scope.
I think it would be valuable for the Keycloak team to define and publish
what it thinks the terms "scope" and "role" mean and how those
values
propagate through Keycloak (e.g. where do they come from, if they are
synthesized from other values then how). As well as their intended use.
People may be coming to Keycloak with a different set of assumptions on
what those terms mean.
At the same time it would be worthwhile to include a discussion of
groups and how they relate to roles (and scope?). That is because many
applications define and manage roles themselves and assign roles based
on group attributes returned in an assertion/claim attribute. Typically
we have not expected an IdP to assign roles to a user. In an application
which supports multiple IdP's (other than Keycloak, e.g. federation) you
simply cannot assume the IdP can map a user into a role. Mapping a user
into a role is usually application specific logic synthesized from
attributes bound to the user principal.
I guess we share the same ideas about roles and groups.
Scopes are heavily mentioned by both OAuth2 and OIDC specs and they usually limit the
authorization granted to the client by the resource owner.
Scopes have a pretty broad meaning as they can represent a single attribute, a group of
attributes, an action on a particular resource managed by a resource server, etc. Even
roles can have a scope, so you are basically saying that a client is allowed to access
that info on behalf of the user or resource owner.
In Keycloak, you can grant roles directly to an user or to the group he belongs to. But
that doesn't mean that you can't do your own role mapping based on the claims
returned within an access token. I share the same opinion about federation and multiple
IdP scenarios, but there are a lot of people that also expect the IdP granting roles to an
user. Specially when there is an 1:N mapping between IdPs and SPs.
Beside that, you would usually prefer assign roles to a group (group of users) than to
each user individually. It makes management easier ...
--
John
2:29 p.m.
On 30/06/16 21:42, Pedro Igor Silva wrote:
----- Original Message -----
> From: "Marek Posolda" <mposolda(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Thursday, June 30, 2016 10:56:04 AM
> Subject: [keycloak-dev] Scope parameter support
>
> IMO We will also need some more flexible way to specify how the value of
> scope parameter will be mapped to roles and protocolMappers. For example
> if I use "scope=foo", it can mean that I want realm role "foo1",
client
> role "client1/foo2" and protocolMapper for "firstName" and
"lastName" etc.
+1. I think I have mentioned something like that on a previous thread, where we should be
able to build scopes from attributes (eg.: from user) or even compose a scope based on
multiple attributes. The same concept applies to protocol mappers, just like you
proposed.
> I can see 2 possibilities:
>
> a) Configure allowed scope param separately per each role / protocolMapper
>
> If some role has "Scope param required" checked, you will have
> possibility to configure list of available values of scope parameter,
> which this role will be applied to. This will be configured per-each
> role separately.
>
> Example: I have realm role "foo" . I check "scope param required"
to
> true. Then I will define "scope param values" : "bar" and
"baz". It
> means that if someone uses parameter "scope=bar" or
> scope=baz", then role "foo" will be applied to token. Otherwise it
won't
> be applied.
>
> Similarly it will be for protocolMappers. We will add switch "Scope
> param required" to protocolMappers and we will use list of available
> values of scope parameter, which is configured per each protocolMapper
> separately.
IMO, roles and scopes are separated concepts. Where scopes may also implicate access to
the roles granted to an user. Scopes have a pretty broad meaning.
With that in mind, don't you think that we could just have a scope "roles"
? Which could be used to ask for the roles associated with the user that the client is
acting on behalf of ?
IMO it will be good that scope can be used to limit/extend the
both
protocolMappers and roles. For example we use "scope=offline_access" for
offline tokens, so the role is applied just if it's included in scope
parameter. Then user may also need to grant this role access on consent
screen.
So just scope "roles" may not be sufficient for fine-grained chose of
roles IMO.
Marek
I think that the Protocol Mappers (for OIDC) provide pretty much everything you need. The
missing part would be to make it capable of grouping other mappers. Actually, the concept
behind a protocol mapper is pretty much
related with a scope.
2:46 p.m.
I'm definitively leaning towards introducing a new concept called scopes,
rather than trying to shoehorn this into roles.
On 1 July 2016 at 14:29, Marek Posolda <mposolda(a)redhat.com> wrote:
On 30/06/16 21:42, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Thursday, June 30, 2016 10:56:04 AM
>> Subject: [keycloak-dev] Scope parameter support
>>
>> IMO We will also need some more flexible way to specify how the value of
>> scope parameter will be mapped to roles and protocolMappers. For example
>> if I use "scope=foo", it can mean that I want realm role
"foo1", client
>> role "client1/foo2" and protocolMapper for "firstName" and
"lastName"
etc.
> +1. I think I have mentioned something like that on a previous thread,
where we should be able to build scopes from attributes (eg.: from user) or
even compose a scope based on multiple attributes. The same concept applies
to protocol mappers, just like you proposed.
>
>> I can see 2 possibilities:
>>
>> a) Configure allowed scope param separately per each role /
protocolMapper
>>
>> If some role has "Scope param required" checked, you will have
>> possibility to configure list of available values of scope parameter,
>> which this role will be applied to. This will be configured per-each
>> role separately.
>>
>> Example: I have realm role "foo" . I check "scope param
required" to
>> true. Then I will define "scope param values" : "bar" and
"baz". It
>> means that if someone uses parameter "scope=bar" or
>> scope=baz", then role "foo" will be applied to token. Otherwise
it won't
>> be applied.
>>
>> Similarly it will be for protocolMappers. We will add switch "Scope
>> param required" to protocolMappers and we will use list of available
>> values of scope parameter, which is configured per each protocolMapper
>> separately.
> IMO, roles and scopes are separated concepts. Where scopes may also
implicate access to the roles granted to an user. Scopes have a pretty
broad meaning.
>
> With that in mind, don't you think that we could just have a scope
"roles" ? Which could be used to ask for the roles associated with the user
that the client is acting on behalf of ?
IMO it will be good that scope can be used to limit/extend the both
protocolMappers and roles. For example we use "scope=offline_access" for
offline tokens, so the role is applied just if it's included in scope
parameter. Then user may also need to grant this role access on consent
screen.
So just scope "roles" may not be sufficient for fine-grained chose of
roles IMO.
Marek
>
> I think that the Protocol Mappers (for OIDC) provide pretty much
everything you need. The missing part would be to make it capable of
grouping other mappers. Actually, the concept behind a protocol mapper is
pretty much
> related with a scope.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:37 a.m.
I don't like option (a) as it would be very clear what scopes are available
and what they result in. You'd have to search through all roles and
protocol mappers to find a list of scopes as well as somehow manually build
the picture of what a scope implies.
A scope could affect:
* Behavior - for example openid and offline_access. We can hard code those,
but what about others and custom ones?
* Roles - limit what roles are included. This is probably the simplest case
as it's just about removing roles.
* Claims - limit what claims are included in the token. This boils down to
protocol mappers. Some protocol mappers would want to be included/excluded
based on scope, but I can also see that some protocol mappers would
internally look at scope to determine what to include.
* Authorization - could also affect authorization separately? The token
contains the scope param separately, so authorization policies could be
written directly on scope rather than roles/attributes
Another thing is that the consent screen (and also showing application
access in account management console) should probably take about scope
rather than individual roles. For example:
* Gallery wants to view your personal details
* Backup application wants to access your photos
A few more points:
* It should be possible to view scopes available for a realm directly, not
by scanning through roles and protocol mappers
* It should be possible to set a description on a scope
* It should be possible to define a scope that maps to multiple roles
* It should be possible to define a scope that maps to multiple protocol
mappers roles
* It may be useful to be able to have protocol mappers that behave
differently depending on the scope. Complexity may outweigh usefulness here
though.
With that in mind I don't think option (a) is great. Option (b) would need
introducing a whole new concept.
How about we use a combination of (a) and (b), by using composite roles?
Something along the lines of:
* scope maps to a role. but the role could be a composite role and hence
expand to other roles.
* Protocol mappers could require a specific role to be applied
* We could add a page to view scopes for a realm
- This would show the corresponding role as well as effective roles if
it's a composite role
- It would also list the protocol mappers included
One more thing is that maybe when a composite role is used on the consent
screen we could have an option if the composite role description should be
shown rather than the individual roles?
On 30 June 2016 at 15:56, Marek Posolda <mposolda(a)redhat.com> wrote:
It seems that for OIDC certification, we will need more proper
support
for "scope" parameter. There are few tests from OIDC conformance
testsuite, which end with WARNING because of issues with "scope" parameter.
SUMMARY OF SPECS REQUIREMENTS
-----------------------------
- In OIDC specification, the "scope" parameter is actually REQUIRED. And
you must add the scope value "openid" to all authorization requests.
Hence if you don't use "scope=openid", the request is pure OAuth2
request, but it's not OIDC request.
In https://issues.jboss.org/browse/KEYCLOAK-3147 we discuss the
possibility that we should change our adapters and add "scope=openid" to
all requests, and also the possibility to remove IDToken if it's not
OIDC request (and maybe other things). However it may be potential issue
with backward compatibility with older adapters (which don't add
"scope=openid" at all).
- OIDC also prescribes the "scope=offline_access", which you use if you
want offline token. We actually support this as we have realm role
"offline_access", with scopeParamRequired=true . So this role is applied
just if it's included in scope parameter. This is our only support of
scope param actually. ATM we reference the realm roles by name (role
name must match the value of scope parameter) and clientRoles by
"clientId/roleName" . So it's not very flexible and won't work well in
the future with role namespaces.
- OIDC defines four other scope values, which we don't support, with the
meaning like this:
profile
OPTIONAL. This scope value requests access to the End-User's
default profile Claims, which are: "name", "family_name",
"given_name",
"middle_name", "nickname", "preferred_username",
"profile", "picture",
"website", "gender", "birthdate", "zoneinfo",
"locale", and "updated_at".
email
OPTIONAL. This scope value requests access to the "email" and
"email_verified" Claims.
address
OPTIONAL. This scope value requests access to the "address" Claim.
phone
OPTIONAL. This scope value requests access to the "phone_number"
and "phone_number_verified" Claims.
- Not directly related to scopes, however OIDC also has one parameter
"claims" described in section
http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter .
This allows to define some additional claims, which should be included
in IDToken or UserInfo endpoint in addition to claims specified by
"scope" parameter.
HOW TO IMPLEMENT?
-----------------
My current thinking is, that we will have 2 kinds of protocolMappers and
roles.
1) "Always applied" - Those roles/protocolMappers are always applied to
token even if they are not specified by scope parameter.
2) "Applied on demand" - Those roles/protocolMappers are applied just if
they are specifically requested by scope parameter
For roles, we already have that with "scope param required" flag defined
per roleModel. However for protocolMappers we don't have it yet.
IMO We will also need some more flexible way to specify how the value of
scope parameter will be mapped to roles and protocolMappers. For example
if I use "scope=foo", it can mean that I want realm role "foo1",
client
role "client1/foo2" and protocolMapper for "firstName" and
"lastName" etc.
I can see 2 possibilities:
a) Configure allowed scope param separately per each role / protocolMapper
If some role has "Scope param required" checked, you will have
possibility to configure list of available values of scope parameter,
which this role will be applied to. This will be configured per-each
role separately.
Example: I have realm role "foo" . I check "scope param required" to
true. Then I will define "scope param values" : "bar" and
"baz". It
means that if someone uses parameter "scope=bar" or
scope=baz", then role "foo" will be applied to token. Otherwise it
won't
be applied.
Similarly it will be for protocolMappers. We will add switch "Scope
param required" to protocolMappers and we will use list of available
values of scope parameter, which is configured per each protocolMapper
separately.
b) Configure scope parameter in separate place
We will have another tab "Scope parameter config" (or maybe rather
another sub-tab under existing "Scope" tab). Here you will define the
allowed values of scope parameter. For each allowed value, you will
define protocolMappers and roles to apply. Hence for example for
"profile" scope parameter, you will define all protocolMappers for
corresponding claims ( name, family_name, ...) here.
We will still need "scope param required" switch for protocolMappers in
case (b).
My current thinking is to go with (a). So when you go to some role (or
protocolMapper) in admin console you will see if you need scope
parameter and what are available values of scope parameter to request it.
WDYT? Another ideas?
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:34 p.m.
On 01/07/16 09:37, Stian Thorgersen wrote:
I don't like option (a) as it would be very clear what scopes are
available and what they result in. You'd have to search through all
roles and protocol mappers to find a list of scopes as well as somehow
manually build the picture of what a scope implies.
A scope could affect:
* Behavior - for example openid and offline_access. We can hard code
those, but what about others and custom ones?
For "openid", I think we
can hardcode. I was thinking about adding SPI
like ScopeParamMapper or something and drive the behaviour with it,
however it won't work well and will require callbacks in various stages
(ie. IDToken itself is created at some point, but whole
AccessTokenResponse itself and control which tokens go to it is
different point.
For offline_access we already has that driven by realm role actually.
* Roles - limit what roles are included. This is probably the
simplest
case as it's just about removing roles.
Not sure what exactly you mean. For
roles, we already have the
"scopeParamRequired" flag, so we can both include and remove. For
example user is member of roleA, roleB, roleC and they have:
role-a : scopeParamRequired=false
role-b : scopeParamRequired=true
role-c : scopeParamRequired=true
and request will have "scope=role-b" then in token will be included both
role-a and role-b . Just role-c won't be (as it requires
scopeParamRequired but wasn't included in scopeParam).
We currently use it for offline_access role, which is default role, but
have scopeParamRequired, so it's included just if "scope=offline_acces"
is used.
* Claims - limit what claims are included in the token. This boils
down to protocol mappers. Some protocol mappers would want to be
included/excluded based on scope, but I can also see that some
protocol mappers would internally look at scope to determine what to
include.
* Authorization - could also affect authorization separately? The
token contains the scope param separately, so authorization policies
could be written directly on scope rather than roles/attributes
Another thing is that the consent screen (and also showing application
access in account management console) should probably take about scope
rather than individual roles. For example:
* Gallery wants to view your personal details
* Backup application wants to access your photos
A few more points:
* It should be possible to view scopes available for a realm directly,
not by scanning through roles and protocol mappers
* It should be possible to set a description on a scope
* It should be possible to define a scope that maps to multiple roles
* It should be possible to define a scope that maps to multiple
protocol mappers roles
* It may be useful to be able to have protocol mappers that behave
differently depending on the scope. Complexity may outweigh usefulness
here though.
With that in mind I don't think option (a) is great. Option (b) would
need introducing a whole new concept.
How about we use a combination of (a) and (b), by using composite
roles? Something along the lines of:
* scope maps to a role. but the role could be a composite role and
hence expand to other roles.
* Protocol mappers could require a specific role to be applied
* We could add a page to view scopes for a realm
- This would show the corresponding role as well as effective roles
if it's a composite role
- It would also list the protocol mappers included
+1 to this concept and
"mapping" scope param values to roles. However
there are some things to clarify.
- OIDC specs has definition for scopes like "phone" , "email" and
"profile" . So we will need the roles for those. Isn't that confusing a
bit? IMO our RoleModel applies well for the scope parameter, just not
sure if it's not rather mis-using of role concept and bit confusing for
users?
- My understanding is, that scope is per-client thing rather than
per-realm thing? For example if you use "scope=photo", it's applicable
just for client "photogallery". Also the same scope parameter may have
different meaning for different clients ( eg. if you use "scope=admin"
in client "product-app" , the token will receive claims/permissions for
managing products. However using "scope=admin" in client
"customer-app"
, the token will manage customers). So with respect to this, scope looks
to me more like either per-client thing or per-clientTemplate thing (if
some logic is common for more clients).
- We will need some way how to map value of scope parameter to
particular role.
The simple (but probably not correct) way: On role definition, we can
have something like "Scope param value" where you can configure value
"photo" and it would mean that the "scope=photo" is related to this
paricular role.
However what if there are clashes? For example someone can configure the
scope parameter value "photo" for realm role "realm-photo-role" or
client role "photogalery/client-photo-role" . Then when you use
"scope=photo", which one will be used?
So after we add roleNamespaces, I can imagine something like this:
- Each client will have reserved namespace, where all roles mapped to
"scope" parameter lives. Also each clientTemplate will have such namespace.
- After creation of client, there will be a set of corresponding roles
added automatically for the client like:
"prefix:/clients/my-client-id/scope-param/phone"
"prefix:/clients/my-client-id/scope-param/address"
"prefix:/clients/my-client-id/scope-param/profile"
"prefix:/clients/my-client-id/scope-param/offline_access"
You won't need to configure "Scope param name" as that will be based on
the roleName
- Those roles won't be default roles and won't be automatically assigned
to users. However any user, who uses "scope=phone" can request the scope
"phone" with corresponding protocolMappers and children composite roles.
- If role is assigned to user directly, it will be always used even if
it's not used in scope parameter. So user assigned to role "phone" will
automatically receive "phone" and "phone_verified" protocolMappers.
- Keycloak will browse roles from the "scope-param" namespace of
particular client, and then also roles from "scope-param" namespace of
clientTemplate. So clientTemplate can have namespace for scope
parameters, which can be used if there is some "common" scope applicable
to more clients with common set of protocolMappers from this clientTemplate.
- For the scopes like "phone" "address" and "profile"
it's pretty
straightforward. It seems we will need protocolMappers for every OIDC
defined claim (address, phone, gender, birthday etc) and those will have
role required. So for example protocolMapper for "birthday" will require
role "profile" , protocolMapper for "phone" will require role
"phone"
etc. Basic existing protocolMappers ( name, "preferred_username" etc) .
- For the "prefix:/clients/my-client-id/scope-param/offline_access"
role, it will have one composite role, which is current realm role
"offline_access" . The current "offline_access" realm role is default
role with scopeParamRequired=true, so it's applied just if it's
requested (directly or indirectly) through scope parameter. If client
doesn't need offline tokens and "offline_access" scope, the namespaced
role "prefix:/clients/my-client-id/scope-param/offline_access". Also if
you remove realm role "offline_access" from user, you disallow him to
request offline tokens. It's currently realm role, hence it's global
setting (so you can't reject user from offline tokens for "clientA" but
allow him request offline tokens in "clientB") .
Marek
One more thing is that maybe when a composite role is used on the
consent screen we could have an option if the composite role
description should be shown rather than the individual roles?
On 30 June 2016 at 15:56, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
It seems that for OIDC certification, we will need more proper support
for "scope" parameter. There are few tests from OIDC conformance
testsuite, which end with WARNING because of issues with "scope"
parameter.
SUMMARY OF SPECS REQUIREMENTS
-----------------------------
- In OIDC specification, the "scope" parameter is actually
REQUIRED. And
you must add the scope value "openid" to all authorization requests.
Hence if you don't use "scope=openid", the request is pure OAuth2
request, but it's not OIDC request.
In https://issues.jboss.org/browse/KEYCLOAK-3147 we discuss the
possibility that we should change our adapters and add
"scope=openid" to
all requests, and also the possibility to remove IDToken if it's not
OIDC request (and maybe other things). However it may be potential
issue
with backward compatibility with older adapters (which don't add
"scope=openid" at all).
- OIDC also prescribes the "scope=offline_access", which you use
if you
want offline token. We actually support this as we have realm role
"offline_access", with scopeParamRequired=true . So this role is
applied
just if it's included in scope parameter. This is our only support of
scope param actually. ATM we reference the realm roles by name (role
name must match the value of scope parameter) and clientRoles by
"clientId/roleName" . So it's not very flexible and won't work well
in
the future with role namespaces.
- OIDC defines four other scope values, which we don't support,
with the
meaning like this:
profile
OPTIONAL. This scope value requests access to the End-User's
default profile Claims, which are: "name", "family_name",
"given_name",
"middle_name", "nickname", "preferred_username",
"profile", "picture",
"website", "gender", "birthdate", "zoneinfo",
"locale", and
"updated_at".
email
OPTIONAL. This scope value requests access to the "email" and
"email_verified" Claims.
address
OPTIONAL. This scope value requests access to the "address"
Claim.
phone
OPTIONAL. This scope value requests access to the "phone_number"
and "phone_number_verified" Claims.
- Not directly related to scopes, however OIDC also has one parameter
"claims" described in section
http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter .
This allows to define some additional claims, which should be included
in IDToken or UserInfo endpoint in addition to claims specified by
"scope" parameter.
HOW TO IMPLEMENT?
-----------------
My current thinking is, that we will have 2 kinds of
protocolMappers and
roles.
1) "Always applied" - Those roles/protocolMappers are always
applied to
token even if they are not specified by scope parameter.
2) "Applied on demand" - Those roles/protocolMappers are applied
just if
they are specifically requested by scope parameter
For roles, we already have that with "scope param required" flag
defined
per roleModel. However for protocolMappers we don't have it yet.
IMO We will also need some more flexible way to specify how the
value of
scope parameter will be mapped to roles and protocolMappers. For
example
if I use "scope=foo", it can mean that I want realm role "foo1",
client
role "client1/foo2" and protocolMapper for "firstName" and
"lastName" etc.
I can see 2 possibilities:
a) Configure allowed scope param separately per each role /
protocolMapper
If some role has "Scope param required" checked, you will have
possibility to configure list of available values of scope parameter,
which this role will be applied to. This will be configured per-each
role separately.
Example: I have realm role "foo" . I check "scope param required"
to
true. Then I will define "scope param values" : "bar" and
"baz". It
means that if someone uses parameter "scope=bar" or
scope=baz", then role "foo" will be applied to token. Otherwise it
won't
be applied.
Similarly it will be for protocolMappers. We will add switch "Scope
param required" to protocolMappers and we will use list of available
values of scope parameter, which is configured per each protocolMapper
separately.
b) Configure scope parameter in separate place
We will have another tab "Scope parameter config" (or maybe rather
another sub-tab under existing "Scope" tab). Here you will define the
allowed values of scope parameter. For each allowed value, you will
define protocolMappers and roles to apply. Hence for example for
"profile" scope parameter, you will define all protocolMappers for
corresponding claims ( name, family_name, ...) here.
We will still need "scope param required" switch for
protocolMappers in
case (b).
My current thinking is to go with (a). So when you go to some role (or
protocolMapper) in admin console you will see if you need scope
parameter and what are available values of scope parameter to
request it.
WDYT? Another ideas?
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:45 p.m.
On 1 July 2016 at 14:34, Marek Posolda <mposolda(a)redhat.com> wrote:
On 01/07/16 09:37, Stian Thorgersen wrote:
I don't like option (a) as it would be very clear what scopes are
available and what they result in. You'd have to search through all roles
and protocol mappers to find a list of scopes as well as somehow manually
build the picture of what a scope implies.
A scope could affect:
* Behavior - for example openid and offline_access. We can hard code
those, but what about others and custom ones?
For "openid", I think we can hardcode. I was thinking about adding SPI
like ScopeParamMapper or something and drive the behaviour with it, however
it won't work well and will require callbacks in various stages (ie.
IDToken itself is created at some point, but whole AccessTokenResponse
itself and control which tokens go to it is different point.
For offline_access we already has that driven by realm role actually.
* Roles - limit what roles are included. This is probably the simplest
case as it's just about removing roles.
Not sure what exactly you mean. For roles, we already have the
"scopeParamRequired" flag, so we can both include and remove. For example
user is member of roleA, roleB, roleC and they have:
role-a : scopeParamRequired=false
role-b : scopeParamRequired=true
role-c : scopeParamRequired=true
and request will have "scope=role-b" then in token will be included both
role-a and role-b . Just role-c won't be (as it requires scopeParamRequired
but wasn't included in scopeParam).
We currently use it for offline_access role, which is default role, but
have scopeParamRequired, so it's included just if "scope=offline_acces" is
used.
I meant that a single scope should be able to change several things, not
just enable/disable a single role.
* Claims - limit what claims are included in the token. This boils down to
protocol mappers. Some protocol mappers would want to be included/excluded
based on scope, but I can also see that some protocol mappers would
internally look at scope to determine what to include.
* Authorization - could also affect authorization separately? The token
contains the scope param separately, so authorization policies could be
written directly on scope rather than roles/attributes
Another thing is that the consent screen (and also showing application
access in account management console) should probably take about scope
rather than individual roles. For example:
* Gallery wants to view your personal details
* Backup application wants to access your photos
A few more points:
* It should be possible to view scopes available for a realm directly, not
by scanning through roles and protocol mappers
* It should be possible to set a description on a scope
* It should be possible to define a scope that maps to multiple roles
* It should be possible to define a scope that maps to multiple protocol
mappers roles
* It may be useful to be able to have protocol mappers that behave
differently depending on the scope. Complexity may outweigh usefulness here
though.
With that in mind I don't think option (a) is great. Option (b) would need
introducing a whole new concept.
How about we use a combination of (a) and (b), by using composite roles?
Something along the lines of:
* scope maps to a role. but the role could be a composite role and hence
expand to other roles.
* Protocol mappers could require a specific role to be applied
* We could add a page to view scopes for a realm
- This would show the corresponding role as well as effective roles if
it's a composite role
- It would also list the protocol mappers included
+1 to this concept and "mapping" scope param values to roles. However
there are some things to clarify.
- OIDC specs has definition for scopes like "phone" , "email" and
"profile" . So we will need the roles for those. Isn't that confusing a
bit? IMO our RoleModel applies well for the scope parameter, just not sure
if it's not rather mis-using of role concept and bit confusing for users?
Would be better if we had role namespaces as we could then have a OIDC
namespace. That would remove some of the confusion I think.
- My understanding is, that scope is per-client thing rather than
per-realm thing? For example if you use "scope=photo", it's applicable
just
for client "photogallery". Also the same scope parameter may have different
meaning for different clients ( eg. if you use "scope=admin" in client
"product-app" , the token will receive claims/permissions for managing
products. However using "scope=admin" in client "customer-app" , the
token
will manage customers). So with respect to this, scope looks to me more
like either per-client thing or per-clientTemplate thing (if some logic is
common for more clients).
Not sure I full agree with that. I think it can be a per-realm and
per-client thing, at least per group of clients. The scope could affect the
app, services it invokes and also authorization policies. I would actually
think that most organizations would define a "organization" level scopes
rather than per-client scopes.
- We will need some way how to map value of scope parameter to particular
role.
The simple (but probably not correct) way: On role definition, we can have
something like "Scope param value" where you can configure value
"photo"
and it would mean that the "scope=photo" is related to this paricular role.
However what if there are clashes? For example someone can configure the
scope parameter value "photo" for realm role "realm-photo-role" or
client
role "photogalery/client-photo-role" . Then when you use
"scope=photo",
which one will be used?
Why not just use the role name as the scope name? A composite role can be
used to create an "alias" if required.
So after we add roleNamespaces, I can imagine something like this:
- Each client will have reserved namespace, where all roles mapped to
"scope" parameter lives. Also each clientTemplate will have such namespace.
- After creation of client, there will be a set of corresponding roles
added automatically for the client like:
"prefix:/clients/my-client-id/scope-param/phone"
"prefix:/clients/my-client-id/scope-param/address"
"prefix:/clients/my-client-id/scope-param/profile"
"prefix:/clients/my-client-id/scope-param/offline_access"
You won't need to configure "Scope param name" as that will be based on
the roleName
- Those roles won't be default roles and won't be automatically assigned
to users. However any user, who uses "scope=phone" can request the scope
"phone" with corresponding protocolMappers and children composite roles.
- If role is assigned to user directly, it will be always used even if
it's not used in scope parameter. So user assigned to role "phone" will
automatically receive "phone" and "phone_verified" protocolMappers.
- Keycloak will browse roles from the "scope-param" namespace of
particular client, and then also roles from "scope-param" namespace of
clientTemplate. So clientTemplate can have namespace for scope parameters,
which can be used if there is some "common" scope applicable to more
clients with common set of protocolMappers from this clientTemplate.
- For the scopes like "phone" "address" and "profile"
it's pretty
straightforward. It seems we will need protocolMappers for every OIDC
defined claim (address, phone, gender, birthday etc) and those will have
role required. So for example protocolMapper for "birthday" will require
role "profile" , protocolMapper for "phone" will require role
"phone" etc.
Basic existing protocolMappers ( name, "preferred_username" etc) .
- For the "prefix:/clients/my-client-id/scope-param/offline_access" role,
it will have one composite role, which is current realm role
"offline_access" . The current "offline_access" realm role is default
role
with scopeParamRequired=true, so it's applied just if it's requested
(directly or indirectly) through scope parameter. If client doesn't need
offline tokens and "offline_access" scope, the namespaced role
"prefix:/clients/my-client-id/scope-param/offline_access". Also if you
remove realm role "offline_access" from user, you disallow him to request
offline tokens. It's currently realm role, hence it's global setting (so
you can't reject user from offline tokens for "clientA" but allow him
request offline tokens in "clientB") .
Reading all of this makes me think it would be cleaner to introduce a
separate scope concept ;)
A user doesn't have a scope - a user has roles and attributes. Re-using
roles concept for the scope just makes it feel awkward and retrofitted.
Marek
One more thing is that maybe when a composite role is used on the consent
screen we could have an option if the composite role description should be
shown rather than the individual roles?
On 30 June 2016 at 15:56, Marek Posolda <mposolda(a)redhat.com> wrote:
> It seems that for OIDC certification, we will need more proper support
> for "scope" parameter. There are few tests from OIDC conformance
> testsuite, which end with WARNING because of issues with "scope"
> parameter.
>
>
> SUMMARY OF SPECS REQUIREMENTS
> -----------------------------
>
> - In OIDC specification, the "scope" parameter is actually REQUIRED. And
> you must add the scope value "openid" to all authorization requests.
> Hence if you don't use "scope=openid", the request is pure OAuth2
> request, but it's not OIDC request.
>
> In https://issues.jboss.org/browse/KEYCLOAK-3147 we discuss the
> possibility that we should change our adapters and add "scope=openid" to
> all requests, and also the possibility to remove IDToken if it's not
> OIDC request (and maybe other things). However it may be potential issue
> with backward compatibility with older adapters (which don't add
> "scope=openid" at all).
>
>
> - OIDC also prescribes the "scope=offline_access", which you use if you
> want offline token. We actually support this as we have realm role
> "offline_access", with scopeParamRequired=true . So this role is applied
> just if it's included in scope parameter. This is our only support of
> scope param actually. ATM we reference the realm roles by name (role
> name must match the value of scope parameter) and clientRoles by
> "clientId/roleName" . So it's not very flexible and won't work well
in
> the future with role namespaces.
>
>
> - OIDC defines four other scope values, which we don't support, with the
> meaning like this:
>
> profile
> OPTIONAL. This scope value requests access to the End-User's
> default profile Claims, which are: "name", "family_name",
"given_name",
> "middle_name", "nickname", "preferred_username",
"profile", "picture",
> "website", "gender", "birthdate", "zoneinfo",
"locale", and "updated_at".
>
> email
> OPTIONAL. This scope value requests access to the "email" and
> "email_verified" Claims.
>
> address
> OPTIONAL. This scope value requests access to the "address" Claim.
>
> phone
> OPTIONAL. This scope value requests access to the "phone_number"
> and "phone_number_verified" Claims.
>
>
> - Not directly related to scopes, however OIDC also has one parameter
> "claims" described in section
> http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter .
> This allows to define some additional claims, which should be included
> in IDToken or UserInfo endpoint in addition to claims specified by
> "scope" parameter.
>
>
>
> HOW TO IMPLEMENT?
> -----------------
>
> My current thinking is, that we will have 2 kinds of protocolMappers and
> roles.
>
> 1) "Always applied" - Those roles/protocolMappers are always applied to
> token even if they are not specified by scope parameter.
>
> 2) "Applied on demand" - Those roles/protocolMappers are applied just if
> they are specifically requested by scope parameter
>
> For roles, we already have that with "scope param required" flag defined
> per roleModel. However for protocolMappers we don't have it yet.
>
> IMO We will also need some more flexible way to specify how the value of
> scope parameter will be mapped to roles and protocolMappers. For example
> if I use "scope=foo", it can mean that I want realm role "foo1",
client
> role "client1/foo2" and protocolMapper for "firstName" and
"lastName" etc.
>
> I can see 2 possibilities:
>
> a) Configure allowed scope param separately per each role / protocolMapper
>
> If some role has "Scope param required" checked, you will have
> possibility to configure list of available values of scope parameter,
> which this role will be applied to. This will be configured per-each
> role separately.
>
> Example: I have realm role "foo" . I check "scope param required"
to
> true. Then I will define "scope param values" : "bar" and
"baz". It
> means that if someone uses parameter "scope=bar" or
> scope=baz", then role "foo" will be applied to token. Otherwise it
won't
> be applied.
>
> Similarly it will be for protocolMappers. We will add switch "Scope
> param required" to protocolMappers and we will use list of available
> values of scope parameter, which is configured per each protocolMapper
> separately.
>
>
> b) Configure scope parameter in separate place
>
> We will have another tab "Scope parameter config" (or maybe rather
> another sub-tab under existing "Scope" tab). Here you will define the
> allowed values of scope parameter. For each allowed value, you will
> define protocolMappers and roles to apply. Hence for example for
> "profile" scope parameter, you will define all protocolMappers for
> corresponding claims ( name, family_name, ...) here.
>
> We will still need "scope param required" switch for protocolMappers in
> case (b).
>
> My current thinking is to go with (a). So when you go to some role (or
> protocolMapper) in admin console you will see if you need scope
> parameter and what are available values of scope parameter to request it.
>
> WDYT? Another ideas?
>
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
9:45 p.m.
Ok, I wasn't also 100% keen about using role.
Thinking also about what Pedro mentioned before about protocol mappers.
So I wonder that instead of introduce new "scope" concept, we just reuse
protocolMappers SPI and have special impl of protocolMapper, which is
able to deal with scope parameter and aggregate other "children"
protocolMappers and roles?
Something like this:
- There will be new ProtocolMapper implementation like
ScopeAggregatorProtocolMapper. You will define value of scope parameter
(eg. "photo" ) in the configuration of this protocolMapper. Mapper will
be ignored if scope parameter value with this name was not used.
- You will be able to define "children" protocolMappers and "children"
roles in ScopeAggregatorProtocolMapper.
- For each client (and clientTemplate), we will have many defined
protocolMappers, but just some subset of them are "root" mappers, which
are applied by default. The rest of mappers will be used just as
"children" of root mappers. So in client model, we might have:
client.getDefinedProtocolMappers() // all defined
client.getProtocolMappers() // just subset of defined (defacto root
mappers)
- For example: client will have defined protocolMappers: firstName,
lastName, birthday, profile, email. Just "profile" and "email" will be
root mappers. And "profile" is ScopeAggregatorMapper for scope value
"profile" and it's children mappers are : firstName, lastName, birthday.
So then:
-- user will send "scope=profile" . Then defacto all of "firstName",
"lastName", "birthday", "email" claims will be included in
token. On
consent screen will be just "Profile" and "Email"
-- user won't send "scope=profile" . Then defacto just "email"
claim
will be included (So for this example, email is always included even if
not specified by scope parameter).
- With this concept, we are able to aggregate many various claims into
single value of "scope" and on the consent screen have just the roots.
This would fit well for the default scope values mentioned by OIDC
specs. We are also able to define mappers (claims), which will be always
available even if not specified by scope parameter.
- For the roles, I am not 100% sure whether to include them into the
concept or not? However it seems to me that rather yes. The particular
role will be applied into token just if all of those 3 conditions are met:
1) user is member of the role
2) client has scope for the role (so current "scope" tab in clients will
remain as is)
3) if role has scopePAramRequired=true, then it must be included in some
mapper (in other words, those roles are not included directly in
clientSession.getRoles , but it's the responsibility of
ScopeAggregatorProtocolMapper to add them into token if conditions 1+2
are met).
So again, user won't see all children roles on consent screen. Just the
parent protocolMapper.
This will work fine with "scope=offline_access" . There will be
protocolMapper for "offline_access" parameter, which will aggregate just
one children role (the current realm role "offline_access"). The offline
token will be issued just if accessToken will have "offline_access"
permission. So if some client, doesn't need offline tokens, it can just
remove "offline_access" protocolMapper. Also if some user shouldn't be
allowed to request offline tokens, admin can remove him from the
"offline_access" role.
- If some scope parameter is applicable for more clients, it can be
defined on clientTemplate.
PS: I will be on holidays and back on next Thursday 7th July. So sorry
if I won't reply immediately to next mails.
Mare
On 01/07/16 14:57, Pedro Igor Silva wrote:
> Reading all of this makes me think it would be cleaner to
introduce a
> separate scope concept ;)
>
> A user doesn't have a scope - a user has roles and attributes. Re-using roles
> concept for the scope just makes it feel awkward and retrofitted.
+10000
9:47 a.m.
ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite sure
how it would look like to an end-user.
* Are these managed on a separate screen or on the protocol mappers screen?
* How do users define and view scopes, including viewing what
claims/mappers/roles are associated with a scope?
* How does a user add/remove claims, protocol mappers and roles to
a ScopeAggregatorProtocolMapper?
* Do we provide one or more built-in ScopeAggregatorProtocolMapper that are
configurable? I assume so and that users don't have to programatically
define scopes.
* Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
On 1 July 2016 at 21:45, Marek Posolda <mposolda(a)redhat.com> wrote:
Ok, I wasn't also 100% keen about using role.
Thinking also about what Pedro mentioned before about protocol mappers. So
I wonder that instead of introduce new "scope" concept, we just reuse
protocolMappers SPI and have special impl of protocolMapper, which is able
to deal with scope parameter and aggregate other "children" protocolMappers
and roles?
Something like this:
- There will be new ProtocolMapper implementation like
ScopeAggregatorProtocolMapper. You will define value of scope parameter
(eg. "photo" ) in the configuration of this protocolMapper. Mapper will be
ignored if scope parameter value with this name was not used.
- You will be able to define "children" protocolMappers and
"children"
roles in ScopeAggregatorProtocolMapper.
- For each client (and clientTemplate), we will have many defined
protocolMappers, but just some subset of them are "root" mappers, which are
applied by default. The rest of mappers will be used just as "children" of
root mappers. So in client model, we might have:
client.getDefinedProtocolMappers() // all defined
client.getProtocolMappers() // just subset of defined (defacto root
mappers)
- For example: client will have defined protocolMappers: firstName,
lastName, birthday, profile, email. Just "profile" and "email" will
be root
mappers. And "profile" is ScopeAggregatorMapper for scope value
"profile"
and it's children mappers are : firstName, lastName, birthday.
So then:
-- user will send "scope=profile" . Then defacto all of "firstName",
"lastName", "birthday", "email" claims will be included in
token. On
consent screen will be just "Profile" and "Email"
-- user won't send "scope=profile" . Then defacto just "email"
claim will
be included (So for this example, email is always included even if not
specified by scope parameter).
- With this concept, we are able to aggregate many various claims into
single value of "scope" and on the consent screen have just the roots. This
would fit well for the default scope values mentioned by OIDC specs. We are
also able to define mappers (claims), which will be always available even
if not specified by scope parameter.
- For the roles, I am not 100% sure whether to include them into the
concept or not? However it seems to me that rather yes. The particular role
will be applied into token just if all of those 3 conditions are met:
1) user is member of the role
2) client has scope for the role (so current "scope" tab in clients will
remain as is)
3) if role has scopePAramRequired=true, then it must be included in some
mapper (in other words, those roles are not included directly in
clientSession.getRoles , but it's the responsibility of
ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are
met).
So again, user won't see all children roles on consent screen. Just the
parent protocolMapper.
This will work fine with "scope=offline_access" . There will be
protocolMapper for "offline_access" parameter, which will aggregate just
one children role (the current realm role "offline_access"). The offline
token will be issued just if accessToken will have "offline_access"
permission. So if some client, doesn't need offline tokens, it can just
remove "offline_access" protocolMapper. Also if some user shouldn't be
allowed to request offline tokens, admin can remove him from the
"offline_access" role.
- If some scope parameter is applicable for more clients, it can be
defined on clientTemplate.
PS: I will be on holidays and back on next Thursday 7th July. So sorry if
I won't reply immediately to next mails.
Mare
On 01/07/16 14:57, Pedro Igor Silva wrote:
> Reading all of this makes me think it would be cleaner to introduce a
>> separate scope concept ;)
>>
>> A user doesn't have a scope - a user has roles and attributes. Re-using
>> roles
>> concept for the scope just makes it feel awkward and retrofitted.
>>
> +10000
>
9:45 a.m.
On 04/07/16 09:47, Stian Thorgersen wrote:
ScopeAggregatorProtocolMapper sounds interesting, but I'm not
quite
sure how it would look like to an end-user.
* Are these managed on a separate screen or on the protocol mappers
screen?
I am thinking about the protocolMappers screen. Just add another
"type"
of protocolMapper. This means that we don't need to add another
concept/modelType just for scope parameter, but still we can easily
filter/view the available mappers of type 'scope aggregator' (on the
screen with list of all protocolMappers).
* How do users define and view scopes, including viewing what
claims/mappers/roles are associated with a scope?
* How does a user add/remove claims, protocol mappers and roles to
a ScopeAggregatorProtocolMapper?
I am thinking that for roles, you will select the
roles in same way,
like it's in current "Scopes" tab of client (or "role mappings"
tab of
user). Probably very similar UI can be used for selecting "children"
mappers of current protocolMapper though? Something like "Available
mappers" and "Assigned mappers" and buttons like "Add selected"
and
"Remove selected". Also similarly like for roles, you can view in
"Effective mappers" the list of all effective mappers in case that you
have more composed aggregated scopeAggregatorMappers.
For example, if you have mapper for scope parameter "full-profile",
which will have children mappers, that will point to other scope
aggregated mappers : "profile" , "email" and "phone". Hence
in
"Effective mappers" for "full-profile" you will see all the
descendants,
not just the direct children. So you will see also all the simple
attribute mappers like "firstName", "lastName", "birthday",
"phone
number", ...
* Do we provide one or more built-in ScopeAggregatorProtocolMapper
that are configurable? I assume so and that users don't have to
programatically define scopes.
Yes. I think that we should provide those built-in,
which are specified
by OIDC specification. Which is "profile" , "email" ,
"phone" ,
"address". And we will need to define mappers for all their simple
attributes ( "birthday", "gender" , ...) . Those simple mappers like
"birthday" won't be root mappers by default, so they won't be applied
unless the scope parameter is used (for their parent scopeAggregatorMapper).
For backwards compatibility, we will still use the same 'simple' mappers
like now ( username, email, full name, family name, given name) and they
will be added to token by default. The scopeAggregator mappers (and
their corresponding children) will be applied just if the scope
parameter with corresponding value will be used.
* Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
Yes (see above)
Marek
On 1 July 2016 at 21:45, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Ok, I wasn't also 100% keen about using role.
Thinking also about what Pedro mentioned before about protocol
mappers. So I wonder that instead of introduce new "scope"
concept, we just reuse protocolMappers SPI and have special impl
of protocolMapper, which is able to deal with scope parameter and
aggregate other "children" protocolMappers and roles?
Something like this:
- There will be new ProtocolMapper implementation like
ScopeAggregatorProtocolMapper. You will define value of scope
parameter (eg. "photo" ) in the configuration of this
protocolMapper. Mapper will be ignored if scope parameter value
with this name was not used.
- You will be able to define "children" protocolMappers and
"children" roles in ScopeAggregatorProtocolMapper.
- For each client (and clientTemplate), we will have many defined
protocolMappers, but just some subset of them are "root" mappers,
which are applied by default. The rest of mappers will be used
just as "children" of root mappers. So in client model, we might have:
client.getDefinedProtocolMappers() // all defined
client.getProtocolMappers() // just subset of defined (defacto
root mappers)
- For example: client will have defined protocolMappers:
firstName, lastName, birthday, profile, email. Just "profile" and
"email" will be root mappers. And "profile" is
ScopeAggregatorMapper for scope value "profile" and it's children
mappers are : firstName, lastName, birthday.
So then:
-- user will send "scope=profile" . Then defacto all of
"firstName", "lastName", "birthday", "email"
claims will be
included in token. On consent screen will be just "Profile" and
"Email"
-- user won't send "scope=profile" . Then defacto just
"email"
claim will be included (So for this example, email is always
included even if not specified by scope parameter).
- With this concept, we are able to aggregate many various claims
into single value of "scope" and on the consent screen have just
the roots. This would fit well for the default scope values
mentioned by OIDC specs. We are also able to define mappers
(claims), which will be always available even if not specified by
scope parameter.
- For the roles, I am not 100% sure whether to include them into
the concept or not? However it seems to me that rather yes. The
particular role will be applied into token just if all of those 3
conditions are met:
1) user is member of the role
2) client has scope for the role (so current "scope" tab in
clients will remain as is)
3) if role has scopePAramRequired=true, then it must be included
in some mapper (in other words, those roles are not included
directly in clientSession.getRoles , but it's the responsibility
of ScopeAggregatorProtocolMapper to add them into token if
conditions 1+2 are met).
So again, user won't see all children roles on consent screen.
Just the parent protocolMapper.
This will work fine with "scope=offline_access" . There will be
protocolMapper for "offline_access" parameter, which will
aggregate just one children role (the current realm role
"offline_access"). The offline token will be issued just if
accessToken will have "offline_access" permission. So if some
client, doesn't need offline tokens, it can just remove
"offline_access" protocolMapper. Also if some user shouldn't be
allowed to request offline tokens, admin can remove him from the
"offline_access" role.
- If some scope parameter is applicable for more clients, it can
be defined on clientTemplate.
PS: I will be on holidays and back on next Thursday 7th July. So
sorry if I won't reply immediately to next mails.
Mare
On 01/07/16 14:57, Pedro Igor Silva wrote:
Reading all of this makes me think it would be cleaner to
introduce a
separate scope concept ;)
A user doesn't have a scope - a user has roles and
attributes. Re-using roles
concept for the scope just makes it feel awkward and
retrofitted.
+10000
12:07 p.m.
On 7 July 2016 at 09:45, Marek Posolda <mposolda(a)redhat.com> wrote:
> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
>
> Yes (see above)
>
> Marek
> On 1 July 2016 at 21:45, Marek Posolda <mposolda(a)redhat.com> wrote:
>
>> Ok, I wasn't also 100% keen about using role.
>>
>> Thinking also about what Pedro mentioned before about protocol mappers.
>> So I wonder that instead of introduce new "scope" concept, we just
reuse
>> protocolMappers SPI and have special impl of protocolMapper, which is able
>> to deal with scope parameter and aggregate other "children"
protocolMappers
>> and roles?
>>
>> Something like this:
>> - There will be new ProtocolMapper implementation like
>> ScopeAggregatorProtocolMapper. You will define value of scope parameter
>> (eg. "photo" ) in the configuration of this protocolMapper. Mapper will
be
>> ignored if scope parameter value with this name was not used.
>>
>> - You will be able to define "children" protocolMappers and
"children"
>> roles in ScopeAggregatorProtocolMapper.
>>
>> - For each client (and clientTemplate), we will have many defined
>> protocolMappers, but just some subset of them are "root" mappers, which
are
>> applied by default. The rest of mappers will be used just as "children"
of
>> root mappers. So in client model, we might have:
>> client.getDefinedProtocolMappers() // all defined
>> client.getProtocolMappers() // just subset of defined (defacto root
>> mappers)
>>
>> - For example: client will have defined protocolMappers: firstName,
>> lastName, birthday, profile, email. Just "profile" and
"email" will be root
>> mappers. And "profile" is ScopeAggregatorMapper for scope value
"profile"
>> and it's children mappers are : firstName, lastName, birthday.
>>
>> So then:
>> -- user will send "scope=profile" . Then defacto all of
"firstName",
>> "lastName", "birthday", "email" claims will be
included in token. On
>> consent screen will be just "Profile" and "Email"
>> -- user won't send "scope=profile" . Then defacto just
"email" claim will
>> be included (So for this example, email is always included even if not
>> specified by scope parameter).
>>
>> - With this concept, we are able to aggregate many various claims into
>> single value of "scope" and on the consent screen have just the roots.
This
>> would fit well for the default scope values mentioned by OIDC specs. We are
>> also able to define mappers (claims), which will be always available even
>> if not specified by scope parameter.
>>
>> - For the roles, I am not 100% sure whether to include them into the
>> concept or not? However it seems to me that rather yes. The particular role
>> will be applied into token just if all of those 3 conditions are met:
>> 1) user is member of the role
>> 2) client has scope for the role (so current "scope" tab in clients
will
>> remain as is)
>> 3) if role has scopePAramRequired=true, then it must be included in some
>> mapper (in other words, those roles are not included directly in
>> clientSession.getRoles , but it's the responsibility of
>> ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are
>> met).
>>
>> So again, user won't see all children roles on consent screen. Just the
>> parent protocolMapper.
>>
>> This will work fine with "scope=offline_access" . There will be
>> protocolMapper for "offline_access" parameter, which will aggregate
just
>> one children role (the current realm role "offline_access"). The
offline
>> token will be issued just if accessToken will have "offline_access"
>> permission. So if some client, doesn't need offline tokens, it can just
>> remove "offline_access" protocolMapper. Also if some user shouldn't
be
>> allowed to request offline tokens, admin can remove him from the
>> "offline_access" role.
>>
>> - If some scope parameter is applicable for more clients, it can be
>> defined on clientTemplate.
>>
>>
>> PS: I will be on holidays and back on next Thursday 7th July. So sorry if
>> I won't reply immediately to next mails.
>>
>> Mare
>>
>>
>>
>> On 01/07/16 14:57, Pedro Igor Silva wrote:
>>
>>> Reading all of this makes me think it would be cleaner to introduce a
>>>> separate scope concept ;)
>>>>
>>>> A user doesn't have a scope - a user has roles and attributes.
Re-using
>>>> roles
>>>> concept for the scope just makes it feel awkward and retrofitted.
>>>>
>>> +10000
>>>
>>
>
>
On 04/07/16 09:47, Stian Thorgersen wrote:
ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite sure
how it would look like to an end-user.
* Are these managed on a separate screen or on the protocol mappers
screen?
I am thinking about the protocolMappers screen. Just add another "type" of
protocolMapper. This means that we don't need to add another
concept/modelType just for scope parameter, but still we can easily
filter/view the available mappers of type 'scope aggregator' (on the screen
with list of all protocolMappers).
Not quite sure I see why it should be on the protocol mappers screen. As
it's a separate type of mapper as well the UI to define them would be
different I'm not sure I see why it can't be a separate screen.
I think it would fit better on the scope tab. It could have two tabs
"Default scope" and "Scopes" or something like that.
* How do users define and view scopes, including viewing what
claims/mappers/roles are associated with a scope?
* How does a user add/remove claims, protocol mappers and roles to
a ScopeAggregatorProtocolMapper?
I am thinking that for roles, you will select the roles in same way, like
it's in current "Scopes" tab of client (or "role mappings" tab of
user).
Probably very similar UI can be used for selecting "children" mappers of
current protocolMapper though? Something like "Available mappers" and
"Assigned mappers" and buttons like "Add selected" and "Remove
selected".
Also similarly like for roles, you can view in "Effective mappers" the list
of all effective mappers in case that you have more composed aggregated
scopeAggregatorMappers.
For example, if you have mapper for scope parameter "full-profile", which
will have children mappers, that will point to other scope aggregated
mappers : "profile" , "email" and "phone". Hence in
"Effective mappers" for
"full-profile" you will see all the descendants, not just the direct
children. So you will see also all the simple attribute mappers like
"firstName", "lastName", "birthday", "phone
number", ...
Sounds good
* Do we provide one or more built-in ScopeAggregatorProtocolMapper that
are configurable? I assume so and that users don't have to programatically
define scopes.
Yes. I think that we should provide those built-in, which are specified by
OIDC specification. Which is "profile" , "email" , "phone"
, "address". And
we will need to define mappers for all their simple attributes (
"birthday", "gender" , ...) . Those simple mappers like
"birthday" won't be
root mappers by default, so they won't be applied unless the scope
parameter is used (for their parent scopeAggregatorMapper).
For backwards compatibility, we will still use the same 'simple' mappers
like now ( username, email, full name, family name, given name) and they
will be added to token by default. The scopeAggregator mappers (and their
corresponding children) will be applied just if the scope parameter with
corresponding value will be used.
SAML doesn't have this concept does it? If so it probably doesn't even make
sense to show scope mappers for SAML clients.
2:07 p.m.
On 07/07/16 12:07, Stian Thorgersen wrote:
On 7 July 2016 at 09:45, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 04/07/16 09:47, Stian Thorgersen wrote:
> ScopeAggregatorProtocolMapper sounds interesting, but I'm not
> quite sure how it would look like to an end-user.
>
> * Are these managed on a separate screen or on the protocol
> mappers screen?
I am thinking about the protocolMappers screen. Just add another
"type" of protocolMapper. This means that we don't need to add
another concept/modelType just for scope parameter, but still we
can easily filter/view the available mappers of type 'scope
aggregator' (on the screen with list of all protocolMappers).
Not quite sure I see why it should be on the protocol mappers screen.
As it's a separate type of mapper as well the UI to define them would
be different I'm not sure I see why it can't be a separate screen.
I think it would fit better on the scope tab. It could have two tabs
"Default scope" and "Scopes" or something like that.
Not sure
which place is better. However I am maybe slightly more for
protocolMappers screen because:
- It just looks a bit more intuitive to me if all the things, which are
represented at model/DB level by protocolMapper entity are also in admin
console grouped together on single place. But maybe it's just me ;-)
- For the aggregated mapper, you can select that "children" mappers will
be either simple mappers or other aggregated mappers. For example for
the "full-profile" mapper, you can select that it's child is another
aggregated mapper "profile" together with some additional simple mappers
like "first_name" or "last_name" . Hence in the list of available
mappers, you should be able to see both simple and aggregated mappers.
Isn't it then a bit confusing that you will see both the simple mappers
like "firstName" (which are configured in "mappers" tab) together with
aggregated mappers like "profile" (which are configured under
"scope/default scope" tab) together?
Btv. Our current providerModel classes usually have something like:
Map<String, String> config;
on them. However for the aggregated mapper impl, it may be needed to
extend this to:
Map<String, List<String>> config;
as mapper will need to have the property with the list of children
mappers and property with the list of children roles. The question is,
how to represent it in DB? I can see possibilities like:
a) The value at DB level will be just simple string with children values
divided by some delimiter (eg. "mapper123###mapper456###mapper789" )
b) The value will be list at DB level with separate record for every
value (eg. 3 values like "mapper123" , "mapper456" ,
"mapper789" )
It seems the (b) is a bit harder for migration, but likely the more
proper way to address this? It looks like something to keep in mind once
we refactor to the "unified" providerModel table.
> * How do users define and view scopes, including viewing what
> claims/mappers/roles are associated with a scope?
> * How does a user add/remove claims, protocol mappers and roles
> to a ScopeAggregatorProtocolMapper?
I am thinking that for roles, you will select the roles in same
way, like it's in current "Scopes" tab of client (or "role
mappings" tab of user). Probably very similar UI can be used for
selecting "children" mappers of current protocolMapper though?
Something like "Available mappers" and "Assigned mappers" and
buttons like "Add selected" and "Remove selected". Also
similarly
like for roles, you can view in "Effective mappers" the list of
all effective mappers in case that you have more composed
aggregated scopeAggregatorMappers.
For example, if you have mapper for scope parameter
"full-profile", which will have children mappers, that will point
to other scope aggregated mappers : "profile" , "email" and
"phone". Hence in "Effective mappers" for
"full-profile" you will
see all the descendants, not just the direct children. So you will
see also all the simple attribute mappers like "firstName",
"lastName", "birthday", "phone number", ...
Sounds good
> * Do we provide one or more built-in
> ScopeAggregatorProtocolMapper that are configurable? I assume so
> and that users don't have to programatically define scopes.
Yes. I think that we should provide those built-in, which are
specified by OIDC specification. Which is "profile" , "email" ,
"phone" , "address". And we will need to define mappers for all
their simple attributes ( "birthday", "gender" , ...) . Those
simple mappers like "birthday" won't be root mappers by default,
so they won't be applied unless the scope parameter is used (for
their parent scopeAggregatorMapper).
For backwards compatibility, we will still use the same 'simple'
mappers like now ( username, email, full name, family name, given
name) and they will be added to token by default. The
scopeAggregator mappers (and their corresponding children) will be
applied just if the scope parameter with corresponding value will
be used.
SAML doesn't have this concept does it? If so it probably doesn't even
make sense to show scope mappers for SAML clients.
I don't think that SAML has
something like scope parameter. At least I
am not aware of that :-)
However our SAML clients currently have "Scope" tab visible to map which
realm roles (or client roles) are allowed to be put into SAML assertion.
That works same like for OIDC clients and makes sense to keep. I guess
you meant to hide just the new sub-tab of the "Scope" tab for configure
scope parameter?
Marek
> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
Yes (see above)
Marek
>
> On 1 July 2016 at 21:45, Marek Posolda <mposolda(a)redhat.com
> <mailto:mposolda@redhat.com>> wrote:
>
> Ok, I wasn't also 100% keen about using role.
>
> Thinking also about what Pedro mentioned before about
> protocol mappers. So I wonder that instead of introduce new
> "scope" concept, we just reuse protocolMappers SPI and have
> special impl of protocolMapper, which is able to deal with
> scope parameter and aggregate other "children"
> protocolMappers and roles?
>
> Something like this:
> - There will be new ProtocolMapper implementation like
> ScopeAggregatorProtocolMapper. You will define value of
> scope parameter (eg. "photo" ) in the configuration of this
> protocolMapper. Mapper will be ignored if scope parameter
> value with this name was not used.
>
> - You will be able to define "children" protocolMappers and
> "children" roles in ScopeAggregatorProtocolMapper.
>
> - For each client (and clientTemplate), we will have many
> defined protocolMappers, but just some subset of them are
> "root" mappers, which are applied by default. The rest of
> mappers will be used just as "children" of root mappers. So
> in client model, we might have:
> client.getDefinedProtocolMappers() // all defined
> client.getProtocolMappers() // just subset of defined
> (defacto root mappers)
>
> - For example: client will have defined protocolMappers:
> firstName, lastName, birthday, profile, email. Just "profile"
> and "email" will be root mappers. And "profile" is
> ScopeAggregatorMapper for scope value "profile" and it's
> children mappers are : firstName, lastName, birthday.
>
> So then:
> -- user will send "scope=profile" . Then defacto all of
> "firstName", "lastName", "birthday",
"email" claims will be
> included in token. On consent screen will be just "Profile"
> and "Email"
> -- user won't send "scope=profile" . Then defacto just
> "email" claim will be included (So for this example, email is
> always included even if not specified by scope parameter).
>
> - With this concept, we are able to aggregate many various
> claims into single value of "scope" and on the consent screen
> have just the roots. This would fit well for the default
> scope values mentioned by OIDC specs. We are also able to
> define mappers (claims), which will be always available even
> if not specified by scope parameter.
>
> - For the roles, I am not 100% sure whether to include them
> into the concept or not? However it seems to me that rather
> yes. The particular role will be applied into token just if
> all of those 3 conditions are met:
> 1) user is member of the role
> 2) client has scope for the role (so current "scope" tab in
> clients will remain as is)
> 3) if role has scopePAramRequired=true, then it must be
> included in some mapper (in other words, those roles are not
> included directly in clientSession.getRoles , but it's the
> responsibility of ScopeAggregatorProtocolMapper to add them
> into token if conditions 1+2 are met).
>
> So again, user won't see all children roles on consent
> screen. Just the parent protocolMapper.
>
> This will work fine with "scope=offline_access" . There will
> be protocolMapper for "offline_access" parameter, which will
> aggregate just one children role (the current realm role
> "offline_access"). The offline token will be issued just if
> accessToken will have "offline_access" permission. So if some
> client, doesn't need offline tokens, it can just remove
> "offline_access" protocolMapper. Also if some user shouldn't
> be allowed to request offline tokens, admin can remove him
> from the "offline_access" role.
>
> - If some scope parameter is applicable for more clients, it
> can be defined on clientTemplate.
>
>
> PS: I will be on holidays and back on next Thursday 7th July.
> So sorry if I won't reply immediately to next mails.
>
> Mare
>
>
>
> On 01/07/16 14:57, Pedro Igor Silva wrote:
>
> Reading all of this makes me think it would be
> cleaner to introduce a
> separate scope concept ;)
>
> A user doesn't have a scope - a user has roles and
> attributes. Re-using roles
> concept for the scope just makes it feel awkward and
> retrofitted.
>
> +10000
>
>
>
8:22 a.m.
On 8 July 2016 at 14:07, Marek Posolda <mposolda(a)redhat.com> wrote:
On 07/07/16 12:07, Stian Thorgersen wrote:
On 7 July 2016 at 09:45, Marek Posolda <mposolda(a)redhat.com> wrote:
> On 04/07/16 09:47, Stian Thorgersen wrote:
>
> ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite sure
> how it would look like to an end-user.
>
> * Are these managed on a separate screen or on the protocol mappers
> screen?
>
> I am thinking about the protocolMappers screen. Just add another "type"
> of protocolMapper. This means that we don't need to add another
> concept/modelType just for scope parameter, but still we can easily
> filter/view the available mappers of type 'scope aggregator' (on the screen
> with list of all protocolMappers).
>
Not quite sure I see why it should be on the protocol mappers screen. As
it's a separate type of mapper as well the UI to define them would be
different I'm not sure I see why it can't be a separate screen.
I think it would fit better on the scope tab. It could have two tabs
"Default scope" and "Scopes" or something like that.
Not sure which place is better. However I am maybe slightly more for
protocolMappers screen because:
- It just looks a bit more intuitive to me if all the things, which are
represented at model/DB level by protocolMapper entity are also in admin
console grouped together on single place. But maybe it's just me ;-)
- For the aggregated mapper, you can select that "children" mappers will
be either simple mappers or other aggregated mappers. For example for the
"full-profile" mapper, you can select that it's child is another
aggregated
mapper "profile" together with some additional simple mappers like
"first_name" or "last_name" . Hence in the list of available mappers,
you
should be able to see both simple and aggregated mappers.
Isn't it then a bit confusing that you will see both the simple mappers
like "firstName" (which are configured in "mappers" tab) together
with
aggregated mappers like "profile" (which are configured under
"scope/default scope" tab) together?
You lost me a bit here. I think I may have miss understood something you
explained before.
My assumption was that there are two separate things: regular mappers and
scope mappers. Regular mappers are configured as before, while scope
mappers are configured for each scope. So there would be separate screens
in either case. Maybe I'm wrong here, but I could see a page that lists all
scopes, then you can click on the scope to see what mappers are applied as
well as what roles are applied.
Maybe it's time to do some mock screens or wire frames?
Btv. Our current providerModel classes usually have something like:
Map<String, String> config;
on them. However for the aggregated mapper impl, it may be needed to
extend this to:
Map<String, List<String>> config;
as mapper will need to have the property with the list of children mappers
and property with the list of children roles. The question is, how to
represent it in DB? I can see possibilities like:
a) The value at DB level will be just simple string with children values
divided by some delimiter (eg. "mapper123###mapper456###mapper789" )
b) The value will be list at DB level with separate record for every value
(eg. 3 values like "mapper123" , "mapper456" , "mapper789"
)
It seems the (b) is a bit harder for migration, but likely the more proper
way to address this? It looks like something to keep in mind once we
refactor to the "unified" providerModel table.
>
> * How do users define and view scopes, including viewing what
> claims/mappers/roles are associated with a scope?
> * How does a user add/remove claims, protocol mappers and roles to
> a ScopeAggregatorProtocolMapper?
>
> I am thinking that for roles, you will select the roles in same way, like
> it's in current "Scopes" tab of client (or "role mappings"
tab of user).
> Probably very similar UI can be used for selecting "children" mappers of
> current protocolMapper though? Something like "Available mappers" and
> "Assigned mappers" and buttons like "Add selected" and
"Remove selected".
> Also similarly like for roles, you can view in "Effective mappers" the
list
> of all effective mappers in case that you have more composed aggregated
> scopeAggregatorMappers.
>
> For example, if you have mapper for scope parameter "full-profile", which
> will have children mappers, that will point to other scope aggregated
> mappers : "profile" , "email" and "phone". Hence in
"Effective mappers" for
> "full-profile" you will see all the descendants, not just the direct
> children. So you will see also all the simple attribute mappers like
> "firstName", "lastName", "birthday", "phone
number", ...
>
Sounds good
>
> * Do we provide one or more built-in ScopeAggregatorProtocolMapper that
> are configurable? I assume so and that users don't have to programatically
> define scopes.
>
> Yes. I think that we should provide those built-in, which are specified
> by OIDC specification. Which is "profile" , "email" ,
"phone" , "address".
> And we will need to define mappers for all their simple attributes (
> "birthday", "gender" , ...) . Those simple mappers like
"birthday" won't be
> root mappers by default, so they won't be applied unless the scope
> parameter is used (for their parent scopeAggregatorMapper).
>
> For backwards compatibility, we will still use the same 'simple' mappers
> like now ( username, email, full name, family name, given name) and they
> will be added to token by default. The scopeAggregator mappers (and their
> corresponding children) will be applied just if the scope parameter with
> corresponding value will be used.
>
SAML doesn't have this concept does it? If so it probably doesn't even
make sense to show scope mappers for SAML clients.
I don't think that SAML has something like scope parameter. At least I am
not aware of that :-)
However our SAML clients currently have "Scope" tab visible to map which
realm roles (or client roles) are allowed to be put into SAML assertion.
That works same like for OIDC clients and makes sense to keep. I guess you
meant to hide just the new sub-tab of the "Scope" tab for configure scope
parameter?
Marek
>
>
> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
>
> Yes (see above)
>
> Marek
>
>
> On 1 July 2016 at 21:45, Marek Posolda < <mposolda(a)redhat.com>
> mposolda(a)redhat.com> wrote:
>
>> Ok, I wasn't also 100% keen about using role.
>>
>> Thinking also about what Pedro mentioned before about protocol mappers.
>> So I wonder that instead of introduce new "scope" concept, we just
reuse
>> protocolMappers SPI and have special impl of protocolMapper, which is able
>> to deal with scope parameter and aggregate other "children"
protocolMappers
>> and roles?
>>
>> Something like this:
>> - There will be new ProtocolMapper implementation like
>> ScopeAggregatorProtocolMapper. You will define value of scope parameter
>> (eg. "photo" ) in the configuration of this protocolMapper. Mapper will
be
>> ignored if scope parameter value with this name was not used.
>>
>> - You will be able to define "children" protocolMappers and
"children"
>> roles in ScopeAggregatorProtocolMapper.
>>
>> - For each client (and clientTemplate), we will have many defined
>> protocolMappers, but just some subset of them are "root" mappers, which
are
>> applied by default. The rest of mappers will be used just as "children"
of
>> root mappers. So in client model, we might have:
>> client.getDefinedProtocolMappers() // all defined
>> client.getProtocolMappers() // just subset of defined (defacto root
>> mappers)
>>
>> - For example: client will have defined protocolMappers: firstName,
>> lastName, birthday, profile, email. Just "profile" and
"email" will be root
>> mappers. And "profile" is ScopeAggregatorMapper for scope value
"profile"
>> and it's children mappers are : firstName, lastName, birthday.
>>
>> So then:
>> -- user will send "scope=profile" . Then defacto all of
"firstName",
>> "lastName", "birthday", "email" claims will be
included in token. On
>> consent screen will be just "Profile" and "Email"
>> -- user won't send "scope=profile" . Then defacto just
"email" claim
>> will be included (So for this example, email is always included even if not
>> specified by scope parameter).
>>
>> - With this concept, we are able to aggregate many various claims into
>> single value of "scope" and on the consent screen have just the roots.
This
>> would fit well for the default scope values mentioned by OIDC specs. We are
>> also able to define mappers (claims), which will be always available even
>> if not specified by scope parameter.
>>
>> - For the roles, I am not 100% sure whether to include them into the
>> concept or not? However it seems to me that rather yes. The particular role
>> will be applied into token just if all of those 3 conditions are met:
>> 1) user is member of the role
>> 2) client has scope for the role (so current "scope" tab in clients
will
>> remain as is)
>> 3) if role has scopePAramRequired=true, then it must be included in some
>> mapper (in other words, those roles are not included directly in
>> clientSession.getRoles , but it's the responsibility of
>> ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are
>> met).
>>
>> So again, user won't see all children roles on consent screen. Just the
>> parent protocolMapper.
>>
>> This will work fine with "scope=offline_access" . There will be
>> protocolMapper for "offline_access" parameter, which will aggregate
just
>> one children role (the current realm role "offline_access"). The
offline
>> token will be issued just if accessToken will have "offline_access"
>> permission. So if some client, doesn't need offline tokens, it can just
>> remove "offline_access" protocolMapper. Also if some user shouldn't
be
>> allowed to request offline tokens, admin can remove him from the
>> "offline_access" role.
>>
>> - If some scope parameter is applicable for more clients, it can be
>> defined on clientTemplate.
>>
>>
>> PS: I will be on holidays and back on next Thursday 7th July. So sorry
>> if I won't reply immediately to next mails.
>>
>> Mare
>>
>>
>>
>> On 01/07/16 14:57, Pedro Igor Silva wrote:
>>
>>> Reading all of this makes me think it would be cleaner to introduce a
>>>> separate scope concept ;)
>>>>
>>>> A user doesn't have a scope - a user has roles and attributes.
>>>> Re-using roles
>>>> concept for the scope just makes it feel awkward and retrofitted.
>>>>
>>> +10000
>>>
>>
>>
>
>
9:35 a.m.
On 11/07/16 08:22, Stian Thorgersen wrote:
On 8 July 2016 at 14:07, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 07/07/16 12:07, Stian Thorgersen wrote:
>
>
> On 7 July 2016 at 09:45, Marek Posolda <mposolda(a)redhat.com
> <mailto:mposolda@redhat.com>> wrote:
>
> On 04/07/16 09:47, Stian Thorgersen wrote:
>> ScopeAggregatorProtocolMapper sounds interesting, but I'm
>> not quite sure how it would look like to an end-user.
>>
>> * Are these managed on a separate screen or on the protocol
>> mappers screen?
> I am thinking about the protocolMappers screen. Just add
> another "type" of protocolMapper. This means that we don't
> need to add another concept/modelType just for scope
> parameter, but still we can easily filter/view the available
> mappers of type 'scope aggregator' (on the screen with list
> of all protocolMappers).
>
>
> Not quite sure I see why it should be on the protocol mappers
> screen. As it's a separate type of mapper as well the UI to
> define them would be different I'm not sure I see why it can't be
> a separate screen.
>
> I think it would fit better on the scope tab. It could have two
> tabs "Default scope" and "Scopes" or something like that.
Not sure which place is better. However I am maybe slightly more
for protocolMappers screen because:
- It just looks a bit more intuitive to me if all the things,
which are represented at model/DB level by protocolMapper entity
are also in admin console grouped together on single place. But
maybe it's just me ;-)
- For the aggregated mapper, you can select that "children"
mappers will be either simple mappers or other aggregated mappers.
For example for the "full-profile" mapper, you can select that
it's child is another aggregated mapper "profile" together with
some additional simple mappers like "first_name" or "last_name"
.
Hence in the list of available mappers, you should be able to see
both simple and aggregated mappers.
Isn't it then a bit confusing that you will see both the simple
mappers like "firstName" (which are configured in "mappers" tab)
together with aggregated mappers like "profile" (which are
configured under "scope/default scope" tab) together?
You lost me a bit here. I think I may have miss understood something
you explained before.
My assumption was that there are two separate things: regular mappers
and scope mappers. Regular mappers are configured as before, while
scope mappers are configured for each scope. So there would be
separate screens in either case. Maybe I'm wrong here, but I could see
a page that lists all scopes, then you can click on the scope to see
what mappers are applied as well as what roles are applied.
I was thinking about
ScopeAggregatedMapper just like about another
implementation of ProtocolMapper interface. No another special model or
special mapper type, which Keycloak needs to deal with. The Keycloak
(TokenManager) will treat like any other mapper, so will just call
"transformAccessToken" to it and ScopeAggregatedMapper impl will
delegate to other children mappers and apply roles.
The difference is, that UI will need to be a bit special then for other
mappers. There is possibility that we will add the support showing list
of roles and protocolMappers to the directive "kc-provider-config" .
However it looks the better option might be that particular
protocolMapper implementation (or particular provider implementation in
general) has a way to override the angular template with it's own UI if
it wants to do it.
For example, if there is protocolMapper provider with id "foo" then
angular will:
- First look if there is special screen "protocol-mapper-detail_foo.html" .
- If the screen doesn't exist, it will fallback to default
"protocol-mapper-detail.html" screen with the "kc-provider-config"
directive for generic properties.
For the protocolMapper, the scopeAggregatedMapper will have special
screen "protocol-mapper-detail_scope-aggregate.html" when all other
impls just use the generic screen like now.
Maybe it's time to do some mock screens or wire frames?
+1
or start prototyping and see how it goes? :)
Marek
Btv. Our current providerModel classes usually have something like:
Map<String, String> config;
on them. However for the aggregated mapper impl, it may be needed
to extend this to:
Map<String, List<String>> config;
as mapper will need to have the property with the list of children
mappers and property with the list of children roles. The question
is, how to represent it in DB? I can see possibilities like:
a) The value at DB level will be just simple string with children
values divided by some delimiter (eg.
"mapper123###mapper456###mapper789" )
b) The value will be list at DB level with separate record for
every value (eg. 3 values like "mapper123" , "mapper456" ,
"mapper789" )
It seems the (b) is a bit harder for migration, but likely the
more proper way to address this? It looks like something to keep
in mind once we refactor to the "unified" providerModel table.
>
>> * How do users define and view scopes, including viewing
>> what claims/mappers/roles are associated with a scope?
>> * How does a user add/remove claims, protocol mappers and
>> roles to a ScopeAggregatorProtocolMapper?
> I am thinking that for roles, you will select the roles in
> same way, like it's in current "Scopes" tab of client (or
> "role mappings" tab of user). Probably very similar UI can be
> used for selecting "children" mappers of current
> protocolMapper though? Something like "Available mappers" and
> "Assigned mappers" and buttons like "Add selected" and
> "Remove selected". Also similarly like for roles, you can
> view in "Effective mappers" the list of all effective mappers
> in case that you have more composed aggregated
> scopeAggregatorMappers.
>
> For example, if you have mapper for scope parameter
> "full-profile", which will have children mappers, that will
> point to other scope aggregated mappers : "profile" ,
"email"
> and "phone". Hence in "Effective mappers" for
"full-profile"
> you will see all the descendants, not just the direct
> children. So you will see also all the simple attribute
> mappers like "firstName", "lastName",
"birthday", "phone
> number", ...
>
>
> Sounds good
>
>
>> * Do we provide one or more built-in
>> ScopeAggregatorProtocolMapper that are configurable? I
>> assume so and that users don't have to programatically
>> define scopes.
> Yes. I think that we should provide those built-in, which are
> specified by OIDC specification. Which is "profile" ,
"email"
> , "phone" , "address". And we will need to define mappers
for
> all their simple attributes ( "birthday", "gender" , ...)
.
> Those simple mappers like "birthday" won't be root mappers by
> default, so they won't be applied unless the scope parameter
> is used (for their parent scopeAggregatorMapper).
>
> For backwards compatibility, we will still use the same
> 'simple' mappers like now ( username, email, full name,
> family name, given name) and they will be added to token by
> default. The scopeAggregator mappers (and their corresponding
> children) will be applied just if the scope parameter with
> corresponding value will be used.
>
>
> SAML doesn't have this concept does it? If so it probably doesn't
> even make sense to show scope mappers for SAML clients.
I don't think that SAML has something like scope parameter. At
least I am not aware of that :-)
However our SAML clients currently have "Scope" tab visible to map
which realm roles (or client roles) are allowed to be put into
SAML assertion. That works same like for OIDC clients and makes
sense to keep. I guess you meant to hide just the new sub-tab of
the "Scope" tab for configure scope parameter?
Marek
>
>> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
> Yes (see above)
>
> Marek
>
>>
>> On 1 July 2016 at 21:45, Marek Posolda <mposolda(a)redhat.com
>> <mailto:mposolda@redhat.com>> wrote:
>>
>> Ok, I wasn't also 100% keen about using role.
>>
>> Thinking also about what Pedro mentioned before about
>> protocol mappers. So I wonder that instead of introduce
>> new "scope" concept, we just reuse protocolMappers SPI
>> and have special impl of protocolMapper, which is able
>> to deal with scope parameter and aggregate other
>> "children" protocolMappers and roles?
>>
>> Something like this:
>> - There will be new ProtocolMapper implementation like
>> ScopeAggregatorProtocolMapper. You will define value of
>> scope parameter (eg. "photo" ) in the configuration of
>> this protocolMapper. Mapper will be ignored if scope
>> parameter value with this name was not used.
>>
>> - You will be able to define "children" protocolMappers
>> and "children" roles in ScopeAggregatorProtocolMapper.
>>
>> - For each client (and clientTemplate), we will have
>> many defined protocolMappers, but just some subset of
>> them are "root" mappers, which are applied by default.
>> The rest of mappers will be used just as "children" of
>> root mappers. So in client model, we might have:
>> client.getDefinedProtocolMappers() // all defined
>> client.getProtocolMappers() // just subset of defined
>> (defacto root mappers)
>>
>> - For example: client will have defined protocolMappers:
>> firstName, lastName, birthday, profile, email. Just
>> "profile" and "email" will be root mappers. And
>> "profile" is ScopeAggregatorMapper for scope value
>> "profile" and it's children mappers are : firstName,
>> lastName, birthday.
>>
>> So then:
>> -- user will send "scope=profile" . Then defacto all of
>> "firstName", "lastName", "birthday",
"email" claims will
>> be included in token. On consent screen will be just
>> "Profile" and "Email"
>> -- user won't send "scope=profile" . Then defacto just
>> "email" claim will be included (So for this example,
>> email is always included even if not specified by scope
>> parameter).
>>
>> - With this concept, we are able to aggregate many
>> various claims into single value of "scope" and on the
>> consent screen have just the roots. This would fit well
>> for the default scope values mentioned by OIDC specs. We
>> are also able to define mappers (claims), which will be
>> always available even if not specified by scope parameter.
>>
>> - For the roles, I am not 100% sure whether to include
>> them into the concept or not? However it seems to me
>> that rather yes. The particular role will be applied
>> into token just if all of those 3 conditions are met:
>> 1) user is member of the role
>> 2) client has scope for the role (so current "scope" tab
>> in clients will remain as is)
>> 3) if role has scopePAramRequired=true, then it must be
>> included in some mapper (in other words, those roles are
>> not included directly in clientSession.getRoles , but
>> it's the responsibility of ScopeAggregatorProtocolMapper
>> to add them into token if conditions 1+2 are met).
>>
>> So again, user won't see all children roles on consent
>> screen. Just the parent protocolMapper.
>>
>> This will work fine with "scope=offline_access" . There
>> will be protocolMapper for "offline_access" parameter,
>> which will aggregate just one children role (the current
>> realm role "offline_access"). The offline token will be
>> issued just if accessToken will have "offline_access"
>> permission. So if some client, doesn't need offline
>> tokens, it can just remove "offline_access"
>> protocolMapper. Also if some user shouldn't be allowed
>> to request offline tokens, admin can remove him from the
>> "offline_access" role.
>>
>> - If some scope parameter is applicable for more
>> clients, it can be defined on clientTemplate.
>>
>>
>> PS: I will be on holidays and back on next Thursday 7th
>> July. So sorry if I won't reply immediately to next mails.
>>
>> Mare
>>
>>
>>
>> On 01/07/16 14:57, Pedro Igor Silva wrote:
>>
>> Reading all of this makes me think it would be
>> cleaner to introduce a
>> separate scope concept ;)
>>
>> A user doesn't have a scope - a user has roles
>> and attributes. Re-using roles
>> concept for the scope just makes it feel awkward
>> and retrofitted.
>>
>> +10000
>>
>>
>>
>
>
12:13 p.m.
On 11 July 2016 at 09:35, Marek Posolda <mposolda(a)redhat.com> wrote:
On 11/07/16 08:22, Stian Thorgersen wrote:
On 8 July 2016 at 14:07, Marek Posolda <mposolda(a)redhat.com> wrote:
> On 07/07/16 12:07, Stian Thorgersen wrote:
>
>
>
> On 7 July 2016 at 09:45, Marek Posolda < <mposolda(a)redhat.com>
> mposolda(a)redhat.com> wrote:
>
>> On 04/07/16 09:47, Stian Thorgersen wrote:
>>
>> ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite sure
>> how it would look like to an end-user.
>>
>> * Are these managed on a separate screen or on the protocol mappers
>> screen?
>>
>> I am thinking about the protocolMappers screen. Just add another
"type"
>> of protocolMapper. This means that we don't need to add another
>> concept/modelType just for scope parameter, but still we can easily
>> filter/view the available mappers of type 'scope aggregator' (on the
screen
>> with list of all protocolMappers).
>>
>
> Not quite sure I see why it should be on the protocol mappers screen. As
> it's a separate type of mapper as well the UI to define them would be
> different I'm not sure I see why it can't be a separate screen.
>
> I think it would fit better on the scope tab. It could have two tabs
> "Default scope" and "Scopes" or something like that.
>
> Not sure which place is better. However I am maybe slightly more for
> protocolMappers screen because:
>
> - It just looks a bit more intuitive to me if all the things, which are
> represented at model/DB level by protocolMapper entity are also in admin
> console grouped together on single place. But maybe it's just me ;-)
>
>
> - For the aggregated mapper, you can select that "children" mappers will
> be either simple mappers or other aggregated mappers. For example for the
> "full-profile" mapper, you can select that it's child is another
aggregated
> mapper "profile" together with some additional simple mappers like
> "first_name" or "last_name" . Hence in the list of available
mappers, you
> should be able to see both simple and aggregated mappers.
> Isn't it then a bit confusing that you will see both the simple mappers
> like "firstName" (which are configured in "mappers" tab) together
with
> aggregated mappers like "profile" (which are configured under
> "scope/default scope" tab) together?
>
You lost me a bit here. I think I may have miss understood something you
explained before.
My assumption was that there are two separate things: regular mappers and
scope mappers. Regular mappers are configured as before, while scope
mappers are configured for each scope. So there would be separate screens
in either case. Maybe I'm wrong here, but I could see a page that lists all
scopes, then you can click on the scope to see what mappers are applied as
well as what roles are applied.
I was thinking about ScopeAggregatedMapper just like about another
implementation of ProtocolMapper interface. No another special model or
special mapper type, which Keycloak needs to deal with. The Keycloak
(TokenManager) will treat like any other mapper, so will just call
"transformAccessToken" to it and ScopeAggregatedMapper impl will delegate
to other children mappers and apply roles.
The difference is, that UI will need to be a bit special then for other
mappers. There is possibility that we will add the support showing list of
roles and protocolMappers to the directive "kc-provider-config" . However
it looks the better option might be that particular protocolMapper
implementation (or particular provider implementation in general) has a way
to override the angular template with it's own UI if it wants to do it.
For example, if there is protocolMapper provider with id "foo" then
angular will:
- First look if there is special screen "protocol-mapper-detail_foo.html" .
- If the screen doesn't exist, it will fallback to default
"protocol-mapper-detail.html" screen with the "kc-provider-config"
directive for generic properties.
For the protocolMapper, the scopeAggregatedMapper will have special screen
"protocol-mapper-detail_scope-aggregate.html" when all other impls just use
the generic screen like now.
Maybe it's time to do some mock screens or wire frames?
+1
or start prototyping and see how it goes? :)
Prototyping is just a superior mock ;)
Marek
>
>
> Btv. Our current providerModel classes usually have something like:
>
> Map<String, String> config;
>
> on them. However for the aggregated mapper impl, it may be needed to
> extend this to:
>
> Map<String, List<String>> config;
>
> as mapper will need to have the property with the list of children
> mappers and property with the list of children roles. The question is, how
> to represent it in DB? I can see possibilities like:
> a) The value at DB level will be just simple string with children values
> divided by some delimiter (eg. "mapper123###mapper456###mapper789" )
> b) The value will be list at DB level with separate record for every
> value (eg. 3 values like "mapper123" , "mapper456" ,
"mapper789" )
>
> It seems the (b) is a bit harder for migration, but likely the more
> proper way to address this? It looks like something to keep in mind once we
> refactor to the "unified" providerModel table.
>
>
>
>>
>> * How do users define and view scopes, including viewing what
>> claims/mappers/roles are associated with a scope?
>> * How does a user add/remove claims, protocol mappers and roles to
>> a ScopeAggregatorProtocolMapper?
>>
>> I am thinking that for roles, you will select the roles in same way,
>> like it's in current "Scopes" tab of client (or "role
mappings" tab of
>> user). Probably very similar UI can be used for selecting "children"
>> mappers of current protocolMapper though? Something like "Available
>> mappers" and "Assigned mappers" and buttons like "Add
selected" and "Remove
>> selected". Also similarly like for roles, you can view in "Effective
>> mappers" the list of all effective mappers in case that you have more
>> composed aggregated scopeAggregatorMappers.
>>
>> For example, if you have mapper for scope parameter "full-profile",
>> which will have children mappers, that will point to other scope aggregated
>> mappers : "profile" , "email" and "phone". Hence in
"Effective mappers" for
>> "full-profile" you will see all the descendants, not just the direct
>> children. So you will see also all the simple attribute mappers like
>> "firstName", "lastName", "birthday", "phone
number", ...
>>
>
> Sounds good
>
>
>>
>> * Do we provide one or more built-in ScopeAggregatorProtocolMapper that
>> are configurable? I assume so and that users don't have to programatically
>> define scopes.
>>
>> Yes. I think that we should provide those built-in, which are specified
>> by OIDC specification. Which is "profile" , "email" ,
"phone" , "address".
>> And we will need to define mappers for all their simple attributes (
>> "birthday", "gender" , ...) . Those simple mappers like
"birthday" won't be
>> root mappers by default, so they won't be applied unless the scope
>> parameter is used (for their parent scopeAggregatorMapper).
>>
>> For backwards compatibility, we will still use the same 'simple' mappers
>> like now ( username, email, full name, family name, given name) and they
>> will be added to token by default. The scopeAggregator mappers (and their
>> corresponding children) will be applied just if the scope parameter with
>> corresponding value will be used.
>>
>
> SAML doesn't have this concept does it? If so it probably doesn't even
> make sense to show scope mappers for SAML clients.
>
> I don't think that SAML has something like scope parameter. At least I am
> not aware of that :-)
>
> However our SAML clients currently have "Scope" tab visible to map which
> realm roles (or client roles) are allowed to be put into SAML assertion.
> That works same like for OIDC clients and makes sense to keep. I guess you
> meant to hide just the new sub-tab of the "Scope" tab for configure scope
> parameter?
>
> Marek
>
>
>
>>
>>
>
>> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
>>
>> Yes (see above)
>>
>> Marek
>>
>>
>> On 1 July 2016 at 21:45, Marek Posolda < <mposolda(a)redhat.com>
>> mposolda(a)redhat.com> wrote:
>>
>>> Ok, I wasn't also 100% keen about using role.
>>>
>>> Thinking also about what Pedro mentioned before about protocol mappers.
>>> So I wonder that instead of introduce new "scope" concept, we just
reuse
>>> protocolMappers SPI and have special impl of protocolMapper, which is able
>>> to deal with scope parameter and aggregate other "children"
protocolMappers
>>> and roles?
>>>
>>> Something like this:
>>> - There will be new ProtocolMapper implementation like
>>> ScopeAggregatorProtocolMapper. You will define value of scope parameter
>>> (eg. "photo" ) in the configuration of this protocolMapper. Mapper
will be
>>> ignored if scope parameter value with this name was not used.
>>>
>>> - You will be able to define "children" protocolMappers and
"children"
>>> roles in ScopeAggregatorProtocolMapper.
>>>
>>> - For each client (and clientTemplate), we will have many defined
>>> protocolMappers, but just some subset of them are "root" mappers,
which are
>>> applied by default. The rest of mappers will be used just as
"children" of
>>> root mappers. So in client model, we might have:
>>> client.getDefinedProtocolMappers() // all defined
>>> client.getProtocolMappers() // just subset of defined (defacto root
>>> mappers)
>>>
>>> - For example: client will have defined protocolMappers: firstName,
>>> lastName, birthday, profile, email. Just "profile" and
"email" will be root
>>> mappers. And "profile" is ScopeAggregatorMapper for scope value
"profile"
>>> and it's children mappers are : firstName, lastName, birthday.
>>>
>>> So then:
>>> -- user will send "scope=profile" . Then defacto all of
"firstName",
>>> "lastName", "birthday", "email" claims will be
included in token. On
>>> consent screen will be just "Profile" and "Email"
>>> -- user won't send "scope=profile" . Then defacto just
"email" claim
>>> will be included (So for this example, email is always included even if not
>>> specified by scope parameter).
>>>
>>> - With this concept, we are able to aggregate many various claims into
>>> single value of "scope" and on the consent screen have just the
roots. This
>>> would fit well for the default scope values mentioned by OIDC specs. We are
>>> also able to define mappers (claims), which will be always available even
>>> if not specified by scope parameter.
>>>
>>> - For the roles, I am not 100% sure whether to include them into the
>>> concept or not? However it seems to me that rather yes. The particular role
>>> will be applied into token just if all of those 3 conditions are met:
>>> 1) user is member of the role
>>> 2) client has scope for the role (so current "scope" tab in
clients
>>> will remain as is)
>>> 3) if role has scopePAramRequired=true, then it must be included in
>>> some mapper (in other words, those roles are not included directly in
>>> clientSession.getRoles , but it's the responsibility of
>>> ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are
>>> met).
>>>
>>> So again, user won't see all children roles on consent screen. Just the
>>> parent protocolMapper.
>>>
>>> This will work fine with "scope=offline_access" . There will be
>>> protocolMapper for "offline_access" parameter, which will aggregate
just
>>> one children role (the current realm role "offline_access"). The
offline
>>> token will be issued just if accessToken will have
"offline_access"
>>> permission. So if some client, doesn't need offline tokens, it can just
>>> remove "offline_access" protocolMapper. Also if some user
shouldn't be
>>> allowed to request offline tokens, admin can remove him from the
>>> "offline_access" role.
>>>
>>> - If some scope parameter is applicable for more clients, it can be
>>> defined on clientTemplate.
>>>
>>>
>>> PS: I will be on holidays and back on next Thursday 7th July. So sorry
>>> if I won't reply immediately to next mails.
>>>
>>> Mare
>>>
>>>
>>>
>>> On 01/07/16 14:57, Pedro Igor Silva wrote:
>>>
>>>> Reading all of this makes me think it would be cleaner to introduce a
>>>>> separate scope concept ;)
>>>>>
>>>>> A user doesn't have a scope - a user has roles and attributes.
>>>>> Re-using roles
>>>>> concept for the scope just makes it feel awkward and retrofitted.
>>>>>
>>>> +10000
>>>>
>>>
>>>
>>
>>
>
>
2:06 a.m.
Hello folks,
are the conclusions of this discussion regarding scope parameter support
still current or are they already superseded by new insights?
For completeness the JIRA issue for "Scope query parameter support":
https://issues.jboss.org/browse/KEYCLOAK-349
Cheers,
Thomas
2016-07-11 12:13 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
On 11 July 2016 at 09:35, Marek Posolda <mposolda(a)redhat.com> wrote:
> On 11/07/16 08:22, Stian Thorgersen wrote:
>
>
>
> On 8 July 2016 at 14:07, Marek Posolda <mposolda(a)redhat.com> wrote:
>
>> On 07/07/16 12:07, Stian Thorgersen wrote:
>>
>>
>>
>> On 7 July 2016 at 09:45, Marek Posolda < <mposolda(a)redhat.com>
>> mposolda(a)redhat.com> wrote:
>>
>>> On 04/07/16 09:47, Stian Thorgersen wrote:
>>>
>>> ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite
>>> sure how it would look like to an end-user.
>>>
>>> * Are these managed on a separate screen or on the protocol mappers
>>> screen?
>>>
>>> I am thinking about the protocolMappers screen. Just add another
"type"
>>> of protocolMapper. This means that we don't need to add another
>>> concept/modelType just for scope parameter, but still we can easily
>>> filter/view the available mappers of type 'scope aggregator' (on the
screen
>>> with list of all protocolMappers).
>>>
>>
>> Not quite sure I see why it should be on the protocol mappers screen. As
>> it's a separate type of mapper as well the UI to define them would be
>> different I'm not sure I see why it can't be a separate screen.
>>
>> I think it would fit better on the scope tab. It could have two tabs
>> "Default scope" and "Scopes" or something like that.
>>
>> Not sure which place is better. However I am maybe slightly more for
>> protocolMappers screen because:
>>
>> - It just looks a bit more intuitive to me if all the things, which are
>> represented at model/DB level by protocolMapper entity are also in admin
>> console grouped together on single place. But maybe it's just me ;-)
>>
>
>>
>> - For the aggregated mapper, you can select that "children" mappers
will
>> be either simple mappers or other aggregated mappers. For example for the
>> "full-profile" mapper, you can select that it's child is another
aggregated
>> mapper "profile" together with some additional simple mappers like
>> "first_name" or "last_name" . Hence in the list of available
mappers, you
>> should be able to see both simple and aggregated mappers.
>> Isn't it then a bit confusing that you will see both the simple mappers
>> like "firstName" (which are configured in "mappers" tab)
together with
>> aggregated mappers like "profile" (which are configured under
>> "scope/default scope" tab) together?
>>
>
> You lost me a bit here. I think I may have miss understood something you
> explained before.
>
> My assumption was that there are two separate things: regular mappers and
> scope mappers. Regular mappers are configured as before, while scope
> mappers are configured for each scope. So there would be separate screens
> in either case. Maybe I'm wrong here, but I could see a page that lists all
> scopes, then you can click on the scope to see what mappers are applied as
> well as what roles are applied.
>
> I was thinking about ScopeAggregatedMapper just like about another
> implementation of ProtocolMapper interface. No another special model or
> special mapper type, which Keycloak needs to deal with. The Keycloak
> (TokenManager) will treat like any other mapper, so will just call
> "transformAccessToken" to it and ScopeAggregatedMapper impl will delegate
> to other children mappers and apply roles.
>
> The difference is, that UI will need to be a bit special then for other
> mappers. There is possibility that we will add the support showing list of
> roles and protocolMappers to the directive "kc-provider-config" . However
> it looks the better option might be that particular protocolMapper
> implementation (or particular provider implementation in general) has a way
> to override the angular template with it's own UI if it wants to do it.
>
> For example, if there is protocolMapper provider with id "foo" then
> angular will:
> - First look if there is special screen "protocol-mapper-detail_foo.html"
> .
> - If the screen doesn't exist, it will fallback to default
> "protocol-mapper-detail.html" screen with the
"kc-provider-config"
> directive for generic properties.
>
> For the protocolMapper, the scopeAggregatedMapper will have special
> screen "protocol-mapper-detail_scope-aggregate.html" when all other
> impls just use the generic screen like now.
>
>
> Maybe it's time to do some mock screens or wire frames?
>
> +1
>
> or start prototyping and see how it goes? :)
>
Prototyping is just a superior mock ;)
>
>
> Marek
>
>
>
>>
>>
>> Btv. Our current providerModel classes usually have something like:
>>
>> Map<String, String> config;
>>
>> on them. However for the aggregated mapper impl, it may be needed to
>> extend this to:
>>
>> Map<String, List<String>> config;
>>
>> as mapper will need to have the property with the list of children
>> mappers and property with the list of children roles. The question is, how
>> to represent it in DB? I can see possibilities like:
>> a) The value at DB level will be just simple string with children values
>> divided by some delimiter (eg. "mapper123###mapper456###mapper789" )
>> b) The value will be list at DB level with separate record for every
>> value (eg. 3 values like "mapper123" , "mapper456" ,
"mapper789" )
>>
>> It seems the (b) is a bit harder for migration, but likely the more
>> proper way to address this? It looks like something to keep in mind once we
>> refactor to the "unified" providerModel table.
>>
>>
>>
>>>
>>> * How do users define and view scopes, including viewing what
>>> claims/mappers/roles are associated with a scope?
>>> * How does a user add/remove claims, protocol mappers and roles to a
ScopeAggregatorProtocolMapper?
>>>
>>>
>>> I am thinking that for roles, you will select the roles in same way,
>>> like it's in current "Scopes" tab of client (or "role
mappings" tab of
>>> user). Probably very similar UI can be used for selecting
"children"
>>> mappers of current protocolMapper though? Something like "Available
>>> mappers" and "Assigned mappers" and buttons like "Add
selected" and "Remove
>>> selected". Also similarly like for roles, you can view in
"Effective
>>> mappers" the list of all effective mappers in case that you have more
>>> composed aggregated scopeAggregatorMappers.
>>>
>>> For example, if you have mapper for scope parameter
"full-profile",
>>> which will have children mappers, that will point to other scope aggregated
>>> mappers : "profile" , "email" and "phone".
Hence in "Effective mappers" for
>>> "full-profile" you will see all the descendants, not just the
direct
>>> children. So you will see also all the simple attribute mappers like
>>> "firstName", "lastName", "birthday",
"phone number", ...
>>>
>>
>> Sounds good
>>
>>
>>>
>>> * Do we provide one or more built-in ScopeAggregatorProtocolMapper
>>> that are configurable? I assume so and that users don't have to
>>> programatically define scopes.
>>>
>>> Yes. I think that we should provide those built-in, which are specified
>>> by OIDC specification. Which is "profile" , "email" ,
"phone" , "address".
>>> And we will need to define mappers for all their simple attributes (
>>> "birthday", "gender" , ...) . Those simple mappers like
"birthday" won't be
>>> root mappers by default, so they won't be applied unless the scope
>>> parameter is used (for their parent scopeAggregatorMapper).
>>>
>>> For backwards compatibility, we will still use the same 'simple'
>>> mappers like now ( username, email, full name, family name, given name) and
>>> they will be added to token by default. The scopeAggregator mappers (and
>>> their corresponding children) will be applied just if the scope parameter
>>> with corresponding value will be used.
>>>
>>
>> SAML doesn't have this concept does it? If so it probably doesn't even
>> make sense to show scope mappers for SAML clients.
>>
>> I don't think that SAML has something like scope parameter. At least I
>> am not aware of that :-)
>>
>> However our SAML clients currently have "Scope" tab visible to map
which
>> realm roles (or client roles) are allowed to be put into SAML assertion.
>> That works same like for OIDC clients and makes sense to keep. I guess you
>> meant to hide just the new sub-tab of the "Scope" tab for configure
scope
>> parameter?
>>
>> Marek
>>
>>
>>
>>>
>>>
>>
>>> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
>>>
>>> Yes (see above)
>>>
>>> Marek
>>>
>>>
>>> On 1 July 2016 at 21:45, Marek Posolda < <mposolda(a)redhat.com>
>>> mposolda(a)redhat.com> wrote:
>>>
>>>> Ok, I wasn't also 100% keen about using role.
>>>>
>>>> Thinking also about what Pedro mentioned before about protocol
>>>> mappers. So I wonder that instead of introduce new "scope"
concept, we just
>>>> reuse protocolMappers SPI and have special impl of protocolMapper, which
is
>>>> able to deal with scope parameter and aggregate other
"children"
>>>> protocolMappers and roles?
>>>>
>>>> Something like this:
>>>> - There will be new ProtocolMapper implementation like
>>>> ScopeAggregatorProtocolMapper. You will define value of scope
>>>> parameter (eg. "photo" ) in the configuration of this
protocolMapper.
>>>> Mapper will be ignored if scope parameter value with this name was not
used.
>>>>
>>>> - You will be able to define "children" protocolMappers and
"children"
>>>> roles in ScopeAggregatorProtocolMapper.
>>>>
>>>> - For each client (and clientTemplate), we will have many defined
>>>> protocolMappers, but just some subset of them are "root"
mappers, which are
>>>> applied by default. The rest of mappers will be used just as
"children" of
>>>> root mappers. So in client model, we might have:
>>>> client.getDefinedProtocolMappers() // all defined
>>>> client.getProtocolMappers() // just subset of defined (defacto root
>>>> mappers)
>>>>
>>>> - For example: client will have defined protocolMappers: firstName,
>>>> lastName, birthday, profile, email. Just "profile" and
"email" will be root
>>>> mappers. And "profile" is ScopeAggregatorMapper for scope value
"profile"
>>>> and it's children mappers are : firstName, lastName, birthday.
>>>>
>>>> So then:
>>>> -- user will send "scope=profile" . Then defacto all of
"firstName",
>>>> "lastName", "birthday", "email" claims will
be included in token. On
>>>> consent screen will be just "Profile" and "Email"
>>>> -- user won't send "scope=profile" . Then defacto just
"email" claim
>>>> will be included (So for this example, email is always included even if
not
>>>> specified by scope parameter).
>>>>
>>>> - With this concept, we are able to aggregate many various claims into
>>>> single value of "scope" and on the consent screen have just the
roots. This
>>>> would fit well for the default scope values mentioned by OIDC specs. We
are
>>>> also able to define mappers (claims), which will be always available
even
>>>> if not specified by scope parameter.
>>>>
>>>> - For the roles, I am not 100% sure whether to include them into the
>>>> concept or not? However it seems to me that rather yes. The particular
role
>>>> will be applied into token just if all of those 3 conditions are met:
>>>> 1) user is member of the role
>>>> 2) client has scope for the role (so current "scope" tab in
clients
>>>> will remain as is)
>>>> 3) if role has scopePAramRequired=true, then it must be included in
>>>> some mapper (in other words, those roles are not included directly in
>>>> clientSession.getRoles , but it's the responsibility of
>>>> ScopeAggregatorProtocolMapper to add them into token if conditions 1+2
are
>>>> met).
>>>>
>>>> So again, user won't see all children roles on consent screen. Just
>>>> the parent protocolMapper.
>>>>
>>>> This will work fine with "scope=offline_access" . There will
be
>>>> protocolMapper for "offline_access" parameter, which will
aggregate just
>>>> one children role (the current realm role "offline_access").
The offline
>>>> token will be issued just if accessToken will have
"offline_access"
>>>> permission. So if some client, doesn't need offline tokens, it can
just
>>>> remove "offline_access" protocolMapper. Also if some user
shouldn't be
>>>> allowed to request offline tokens, admin can remove him from the
>>>> "offline_access" role.
>>>>
>>>> - If some scope parameter is applicable for more clients, it can be
>>>> defined on clientTemplate.
>>>>
>>>>
>>>> PS: I will be on holidays and back on next Thursday 7th July. So sorry
>>>> if I won't reply immediately to next mails.
>>>>
>>>> Mare
>>>>
>>>>
>>>>
>>>> On 01/07/16 14:57, Pedro Igor Silva wrote:
>>>>
>>>>> Reading all of this makes me think it would be cleaner to introduce
a
>>>>>> separate scope concept ;)
>>>>>>
>>>>>> A user doesn't have a scope - a user has roles and
attributes.
>>>>>> Re-using roles
>>>>>> concept for the scope just makes it feel awkward and
retrofitted.
>>>>>>
>>>>> +10000
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:54 a.m.
Nothing new to report here. If someone wants to contribute it great, but I
doubt we'll find to do it ourselves anytime soon. Would be best to start a
new discussion around it if someone wants to contribute.
On 21 June 2017 at 02:06, Thomas Darimont <thomas.darimont(a)googlemail.com>
wrote:
Hello folks,
are the conclusions of this discussion regarding scope parameter support
still current or are they already superseded by new insights?
For completeness the JIRA issue for "Scope query parameter support":
https://issues.jboss.org/browse/KEYCLOAK-349
Cheers,
Thomas
2016-07-11 12:13 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
>
>
> On 11 July 2016 at 09:35, Marek Posolda <mposolda(a)redhat.com> wrote:
>
>> On 11/07/16 08:22, Stian Thorgersen wrote:
>>
>>
>>
>> On 8 July 2016 at 14:07, Marek Posolda <mposolda(a)redhat.com> wrote:
>>
>>> On 07/07/16 12:07, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 7 July 2016 at 09:45, Marek Posolda < <mposolda(a)redhat.com>
>>> mposolda(a)redhat.com> wrote:
>>>
>>>> On 04/07/16 09:47, Stian Thorgersen wrote:
>>>>
>>>> ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite
>>>> sure how it would look like to an end-user.
>>>>
>>>> * Are these managed on a separate screen or on the protocol mappers
>>>> screen?
>>>>
>>>> I am thinking about the protocolMappers screen. Just add another
>>>> "type" of protocolMapper. This means that we don't need to
add another
>>>> concept/modelType just for scope parameter, but still we can easily
>>>> filter/view the available mappers of type 'scope aggregator' (on
the screen
>>>> with list of all protocolMappers).
>>>>
>>>
>>> Not quite sure I see why it should be on the protocol mappers screen.
>>> As it's a separate type of mapper as well the UI to define them would be
>>> different I'm not sure I see why it can't be a separate screen.
>>>
>>> I think it would fit better on the scope tab. It could have two tabs
>>> "Default scope" and "Scopes" or something like that.
>>>
>>> Not sure which place is better. However I am maybe slightly more for
>>> protocolMappers screen because:
>>>
>>> - It just looks a bit more intuitive to me if all the things, which are
>>> represented at model/DB level by protocolMapper entity are also in admin
>>> console grouped together on single place. But maybe it's just me ;-)
>>>
>>
>>>
>>> - For the aggregated mapper, you can select that "children"
mappers
>>> will be either simple mappers or other aggregated mappers. For example for
>>> the "full-profile" mapper, you can select that it's child is
another
>>> aggregated mapper "profile" together with some additional simple
mappers
>>> like "first_name" or "last_name" . Hence in the list of
available mappers,
>>> you should be able to see both simple and aggregated mappers.
>>> Isn't it then a bit confusing that you will see both the simple mappers
>>> like "firstName" (which are configured in "mappers" tab)
together with
>>> aggregated mappers like "profile" (which are configured under
>>> "scope/default scope" tab) together?
>>>
>>
>> You lost me a bit here. I think I may have miss understood something you
>> explained before.
>>
>> My assumption was that there are two separate things: regular mappers
>> and scope mappers. Regular mappers are configured as before, while scope
>> mappers are configured for each scope. So there would be separate screens
>> in either case. Maybe I'm wrong here, but I could see a page that lists all
>> scopes, then you can click on the scope to see what mappers are applied as
>> well as what roles are applied.
>>
>> I was thinking about ScopeAggregatedMapper just like about another
>> implementation of ProtocolMapper interface. No another special model or
>> special mapper type, which Keycloak needs to deal with. The Keycloak
>> (TokenManager) will treat like any other mapper, so will just call
>> "transformAccessToken" to it and ScopeAggregatedMapper impl will
delegate
>> to other children mappers and apply roles.
>>
>> The difference is, that UI will need to be a bit special then for other
>> mappers. There is possibility that we will add the support showing list of
>> roles and protocolMappers to the directive "kc-provider-config" .
However
>> it looks the better option might be that particular protocolMapper
>> implementation (or particular provider implementation in general) has a way
>> to override the angular template with it's own UI if it wants to do it.
>>
>> For example, if there is protocolMapper provider with id "foo" then
>> angular will:
>> - First look if there is special screen
"protocol-mapper-detail_foo.html"
>> .
>> - If the screen doesn't exist, it will fallback to default
>> "protocol-mapper-detail.html" screen with the
"kc-provider-config"
>> directive for generic properties.
>>
>> For the protocolMapper, the scopeAggregatedMapper will have special
>> screen "protocol-mapper-detail_scope-aggregate.html" when all other
>> impls just use the generic screen like now.
>>
>>
>> Maybe it's time to do some mock screens or wire frames?
>>
>> +1
>>
>> or start prototyping and see how it goes? :)
>>
>
> Prototyping is just a superior mock ;)
>
>
>>
>>
>> Marek
>>
>>
>>
>>>
>>>
>>> Btv. Our current providerModel classes usually have something like:
>>>
>>> Map<String, String> config;
>>>
>>> on them. However for the aggregated mapper impl, it may be needed to
>>> extend this to:
>>>
>>> Map<String, List<String>> config;
>>>
>>> as mapper will need to have the property with the list of children
>>> mappers and property with the list of children roles. The question is, how
>>> to represent it in DB? I can see possibilities like:
>>> a) The value at DB level will be just simple string with children
>>> values divided by some delimiter (eg.
"mapper123###mapper456###mapper789"
>>> )
>>> b) The value will be list at DB level with separate record for every
>>> value (eg. 3 values like "mapper123" , "mapper456" ,
"mapper789" )
>>>
>>> It seems the (b) is a bit harder for migration, but likely the more
>>> proper way to address this? It looks like something to keep in mind once we
>>> refactor to the "unified" providerModel table.
>>>
>>>
>>>
>>>>
>>>> * How do users define and view scopes, including viewing what
>>>> claims/mappers/roles are associated with a scope?
>>>> * How does a user add/remove claims, protocol mappers and roles to
>>>> a ScopeAggregatorProtocolMapper?
>>>>
>>>> I am thinking that for roles, you will select the roles in same way,
>>>> like it's in current "Scopes" tab of client (or "role
mappings" tab of
>>>> user). Probably very similar UI can be used for selecting
"children"
>>>> mappers of current protocolMapper though? Something like "Available
>>>> mappers" and "Assigned mappers" and buttons like "Add
selected" and "Remove
>>>> selected". Also similarly like for roles, you can view in
"Effective
>>>> mappers" the list of all effective mappers in case that you have
more
>>>> composed aggregated scopeAggregatorMappers.
>>>>
>>>> For example, if you have mapper for scope parameter
"full-profile",
>>>> which will have children mappers, that will point to other scope
aggregated
>>>> mappers : "profile" , "email" and "phone".
Hence in "Effective mappers" for
>>>> "full-profile" you will see all the descendants, not just the
direct
>>>> children. So you will see also all the simple attribute mappers like
>>>> "firstName", "lastName", "birthday",
"phone number", ...
>>>>
>>>
>>> Sounds good
>>>
>>>
>>>>
>>>> * Do we provide one or more built-in ScopeAggregatorProtocolMapper
>>>> that are configurable? I assume so and that users don't have to
>>>> programatically define scopes.
>>>>
>>>> Yes. I think that we should provide those built-in, which are
>>>> specified by OIDC specification. Which is "profile" ,
"email" , "phone" ,
>>>> "address". And we will need to define mappers for all their
simple
>>>> attributes ( "birthday", "gender" , ...) . Those
simple mappers like
>>>> "birthday" won't be root mappers by default, so they
won't be applied
>>>> unless the scope parameter is used (for their parent
scopeAggregatorMapper).
>>>>
>>>> For backwards compatibility, we will still use the same 'simple'
>>>> mappers like now ( username, email, full name, family name, given name)
and
>>>> they will be added to token by default. The scopeAggregator mappers (and
>>>> their corresponding children) will be applied just if the scope
parameter
>>>> with corresponding value will be used.
>>>>
>>>
>>> SAML doesn't have this concept does it? If so it probably doesn't
even
>>> make sense to show scope mappers for SAML clients.
>>>
>>> I don't think that SAML has something like scope parameter. At least I
>>> am not aware of that :-)
>>>
>>> However our SAML clients currently have "Scope" tab visible to map
>>> which realm roles (or client roles) are allowed to be put into SAML
>>> assertion. That works same like for OIDC clients and makes sense to keep. I
>>> guess you meant to hide just the new sub-tab of the "Scope" tab
for
>>> configure scope parameter?
>>>
>>> Marek
>>>
>>>
>>>
>>>>
>>>>
>>>
>>>> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
>>>>
>>>> Yes (see above)
>>>>
>>>> Marek
>>>>
>>>>
>>>> On 1 July 2016 at 21:45, Marek Posolda < <mposolda(a)redhat.com>
>>>> mposolda(a)redhat.com> wrote:
>>>>
>>>>> Ok, I wasn't also 100% keen about using role.
>>>>>
>>>>> Thinking also about what Pedro mentioned before about protocol
>>>>> mappers. So I wonder that instead of introduce new "scope"
concept, we just
>>>>> reuse protocolMappers SPI and have special impl of protocolMapper,
which is
>>>>> able to deal with scope parameter and aggregate other
"children"
>>>>> protocolMappers and roles?
>>>>>
>>>>> Something like this:
>>>>> - There will be new ProtocolMapper implementation like
>>>>> ScopeAggregatorProtocolMapper. You will define value of scope
>>>>> parameter (eg. "photo" ) in the configuration of this
protocolMapper.
>>>>> Mapper will be ignored if scope parameter value with this name was
not used.
>>>>>
>>>>> - You will be able to define "children" protocolMappers
and
>>>>> "children" roles in ScopeAggregatorProtocolMapper.
>>>>>
>>>>> - For each client (and clientTemplate), we will have many defined
>>>>> protocolMappers, but just some subset of them are "root"
mappers, which are
>>>>> applied by default. The rest of mappers will be used just as
"children" of
>>>>> root mappers. So in client model, we might have:
>>>>> client.getDefinedProtocolMappers() // all defined
>>>>> client.getProtocolMappers() // just subset of defined (defacto
>>>>> root mappers)
>>>>>
>>>>> - For example: client will have defined protocolMappers: firstName,
>>>>> lastName, birthday, profile, email. Just "profile" and
"email" will be root
>>>>> mappers. And "profile" is ScopeAggregatorMapper for scope
value "profile"
>>>>> and it's children mappers are : firstName, lastName, birthday.
>>>>>
>>>>> So then:
>>>>> -- user will send "scope=profile" . Then defacto all of
"firstName",
>>>>> "lastName", "birthday", "email" claims
will be included in token. On
>>>>> consent screen will be just "Profile" and
"Email"
>>>>> -- user won't send "scope=profile" . Then defacto just
"email" claim
>>>>> will be included (So for this example, email is always included even
if not
>>>>> specified by scope parameter).
>>>>>
>>>>> - With this concept, we are able to aggregate many various claims
>>>>> into single value of "scope" and on the consent screen have
just the roots.
>>>>> This would fit well for the default scope values mentioned by OIDC
specs.
>>>>> We are also able to define mappers (claims), which will be always
available
>>>>> even if not specified by scope parameter.
>>>>>
>>>>> - For the roles, I am not 100% sure whether to include them into the
>>>>> concept or not? However it seems to me that rather yes. The
particular role
>>>>> will be applied into token just if all of those 3 conditions are
met:
>>>>> 1) user is member of the role
>>>>> 2) client has scope for the role (so current "scope" tab in
clients
>>>>> will remain as is)
>>>>> 3) if role has scopePAramRequired=true, then it must be included in
>>>>> some mapper (in other words, those roles are not included directly
in
>>>>> clientSession.getRoles , but it's the responsibility of
>>>>> ScopeAggregatorProtocolMapper to add them into token if conditions
1+2 are
>>>>> met).
>>>>>
>>>>> So again, user won't see all children roles on consent screen.
Just
>>>>> the parent protocolMapper.
>>>>>
>>>>> This will work fine with "scope=offline_access" . There
will be
>>>>> protocolMapper for "offline_access" parameter, which will
aggregate just
>>>>> one children role (the current realm role
"offline_access"). The offline
>>>>> token will be issued just if accessToken will have
"offline_access"
>>>>> permission. So if some client, doesn't need offline tokens, it
can just
>>>>> remove "offline_access" protocolMapper. Also if some user
shouldn't be
>>>>> allowed to request offline tokens, admin can remove him from the
>>>>> "offline_access" role.
>>>>>
>>>>> - If some scope parameter is applicable for more clients, it can be
>>>>> defined on clientTemplate.
>>>>>
>>>>>
>>>>> PS: I will be on holidays and back on next Thursday 7th July. So
>>>>> sorry if I won't reply immediately to next mails.
>>>>>
>>>>> Mare
>>>>>
>>>>>
>>>>>
>>>>> On 01/07/16 14:57, Pedro Igor Silva wrote:
>>>>>
>>>>>> Reading all of this makes me think it would be cleaner to
introduce a
>>>>>>> separate scope concept ;)
>>>>>>>
>>>>>>> A user doesn't have a scope - a user has roles and
attributes.
>>>>>>> Re-using roles
>>>>>>> concept for the scope just makes it feel awkward and
retrofitted.
>>>>>>>
>>>>>> +10000
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
2501
days inactive
2857
days old
19 comments
5 participants
participants (5)
-
John Dennis -
Marek Posolda -
Pedro Igor Silva -
Stian Thorgersen -
Thomas Darimont