<div dir="ltr"><div>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.</div><div><br></div><div>A scope could affect:</div><div><br></div><div>* Behavior - for example openid and offline_access. We can hard code those, but what about others and custom ones?</div><div>* Roles - limit what roles are included. This is probably the simplest case as it's just about removing roles.</div><div>* 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.</div><div>* 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</div><div><br></div><div>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:</div><div><br></div><div>* Gallery wants to view your personal details</div><div>* Backup application wants to access your photos</div><div><br></div><div>A few more points:</div><div><br></div><div>* It should be possible to view scopes available for a realm directly, not by scanning through roles and protocol mappers</div><div>* It should be possible to set a description on a scope</div><div>* It should be possible to define a scope that maps to multiple roles</div><div>* It should be possible to define a scope that maps to multiple protocol mappers roles</div><div>* It may be useful to be able to have protocol mappers that behave differently depending on the scope. Complexity may outweigh usefulness here though.<br></div><div><br></div><div>With that in mind I don't think option (a) is great. Option (b) would need introducing a whole new concept.</div><div><br></div><div>How about we use a combination of (a) and (b), by using composite roles? Something along the lines of:</div><div><br></div><div>* scope maps to a role. but the role could be a composite role and hence expand to other roles.</div><div>* Protocol mappers could require a specific role to be applied</div><div>* We could add a page to view scopes for a realm</div><div> - This would show the corresponding role as well as effective roles if it's a composite role</div><div> - It would also list the protocol mappers included</div><div><br></div><div>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?</div><div class="gmail_extra"><br><div class="gmail_quote">On 30 June 2016 at 15:56, Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It seems that for OIDC certification, we will need more proper support<br>
for "scope" parameter. There are few tests from OIDC conformance<br>
testsuite, which end with WARNING because of issues with "scope" parameter.<br>
<br>
<br>
SUMMARY OF SPECS REQUIREMENTS<br>
-----------------------------<br>
<br>
- In OIDC specification, the "scope" parameter is actually REQUIRED. And<br>
you must add the scope value "openid" to all authorization requests.<br>
Hence if you don't use "scope=openid", the request is pure OAuth2<br>
request, but it's not OIDC request.<br>
<br>
In <a href="https://issues.jboss.org/browse/KEYCLOAK-3147" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3147</a> we discuss the<br>
possibility that we should change our adapters and add "scope=openid" to<br>
all requests, and also the possibility to remove IDToken if it's not<br>
OIDC request (and maybe other things). However it may be potential issue<br>
with backward compatibility with older adapters (which don't add<br>
"scope=openid" at all).<br>
<br>
<br>
- OIDC also prescribes the "scope=offline_access", which you use if you<br>
want offline token. We actually support this as we have realm role<br>
"offline_access", with scopeParamRequired=true . So this role is applied<br>
just if it's included in scope parameter. This is our only support of<br>
scope param actually. ATM we reference the realm roles by name (role<br>
name must match the value of scope parameter) and clientRoles by<br>
"clientId/roleName" . So it's not very flexible and won't work well in<br>
the future with role namespaces.<br>
<br>
<br>
- OIDC defines four other scope values, which we don't support, with the<br>
meaning like this:<br>
<br>
profile<br>
OPTIONAL. This scope value requests access to the End-User's<br>
default profile Claims, which are: "name", "family_name", "given_name",<br>
"middle_name", "nickname", "preferred_username", "profile", "picture",<br>
"website", "gender", "birthdate", "zoneinfo", "locale", and "updated_at".<br>
<br>
email<br>
OPTIONAL. This scope value requests access to the "email" and<br>
"email_verified" Claims.<br>
<br>
address<br>
OPTIONAL. This scope value requests access to the "address" Claim.<br>
<br>
phone<br>
OPTIONAL. This scope value requests access to the "phone_number"<br>
and "phone_number_verified" Claims.<br>
<br>
<br>
- Not directly related to scopes, however OIDC also has one parameter<br>
"claims" described in section<br>
<a href="http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter" rel="noreferrer" target="_blank">http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter</a> .<br>
This allows to define some additional claims, which should be included<br>
in IDToken or UserInfo endpoint in addition to claims specified by<br>
"scope" parameter.<br>
<br>
<br>
<br>
HOW TO IMPLEMENT?<br>
-----------------<br>
<br>
My current thinking is, that we will have 2 kinds of protocolMappers and<br>
roles.<br>
<br>
1) "Always applied" - Those roles/protocolMappers are always applied to<br>
token even if they are not specified by scope parameter.<br>
<br>
2) "Applied on demand" - Those roles/protocolMappers are applied just if<br>
they are specifically requested by scope parameter<br>
<br>
For roles, we already have that with "scope param required" flag defined<br>
per roleModel. However for protocolMappers we don't have it yet.<br>
<br>
IMO We will also need some more flexible way to specify how the value of<br>
scope parameter will be mapped to roles and protocolMappers. For example<br>
if I use "scope=foo", it can mean that I want realm role "foo1", client<br>
role "client1/foo2" and protocolMapper for "firstName" and "lastName" etc.<br>
<br>
I can see 2 possibilities:<br>
<br>
a) Configure allowed scope param separately per each role / protocolMapper<br>
<br>
If some role has "Scope param required" checked, you will have<br>
possibility to configure list of available values of scope parameter,<br>
which this role will be applied to. This will be configured per-each<br>
role separately.<br>
<br>
Example: I have realm role "foo" . I check "scope param required" to<br>
true. Then I will define "scope param values" : "bar" and "baz". It<br>
means that if someone uses parameter "scope=bar" or<br>
scope=baz", then role "foo" will be applied to token. Otherwise it won't<br>
be applied.<br>
<br>
Similarly it will be for protocolMappers. We will add switch "Scope<br>
param required" to protocolMappers and we will use list of available<br>
values of scope parameter, which is configured per each protocolMapper<br>
separately.<br>
<br>
<br>
b) Configure scope parameter in separate place<br>
<br>
We will have another tab "Scope parameter config" (or maybe rather<br>
another sub-tab under existing "Scope" tab). Here you will define the<br>
allowed values of scope parameter. For each allowed value, you will<br>
define protocolMappers and roles to apply. Hence for example for<br>
"profile" scope parameter, you will define all protocolMappers for<br>
corresponding claims ( name, family_name, ...) here.<br>
<br>
We will still need "scope param required" switch for protocolMappers in<br>
case (b).<br>
<br>
My current thinking is to go with (a). So when you go to some role (or<br>
protocolMapper) in admin console you will see if you need scope<br>
parameter and what are available values of scope parameter to request it.<br>
<br>
WDYT? Another ideas?<br>
<br>
<br>
Marek<br>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</blockquote></div><br></div></div>