[keycloak-dev] Scope parameter support

[Stian Thorgersen]

On 12 February 2018 at 14:57, Marek Posolda <mposolda at redhat.com> wrote:

> On 12/02/18 09:49, Stian Thorgersen wrote:
>
>
>
> On 9 February 2018 at 14:30, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Hi,
>>
>> started looking at OAuth Scope parameter support. Wanted to clarify some
>> things before start implementing:
>>
>> - Client Scope will allow to group protocolMappers and Role Scope
>> Mappings. Pretty similar to current Client Template
>>
>>
>> - Do we want to get rid of "Client templates" entirely and rename them
>> to "Client Scopes" ? Or introduce Client scopes as separate thing in
>> addition to client templates? My vote is to rename and get rid of client
>> templates. It would mean get rid of new option "Login theme" from client
>> template (client scope) then? As otherwise is unclear from which Client
>> Scope will client inherit it (assuming client can be inherit from
>> multiple Client Scopes, not just from single Client Template like is now).
>>
>
> Removing "Login theme" from client template is fine.
>
> Client templates do have a nice benefit of allowing defining some protocol
> mappers and scope that is shared between clients. That can probably be done
> by having the option to set a default scope for a client perhaps?
>
> Yes, should work that way.
>
>
>
>>
>>
>> - Client can inherit from more Client Scopes. I can see 2 groups:
>> -- Default Client Scopes - Those will be applied even if not requested
>> by OIDC scope parameter
>> -- Optional Client Scopes - Those will be applied just if requested by
>> OIDC scope parameter
>>
>
> For default client scope, is there global defaults as well as client
> defaults?
>
> Yes, I think "global defaults" will be good. Those will be added when you
> create new client. You then have possibility to remove some if you want.
>
> I am thinking that "global default" can contain the OIDC predefined scopes
> (email, address, profile, phone) and the scope for all-roles described
> below.
>
>
>
>>
>> - Do we still want to keep ProtocolMappers per client and
>> Role-Scope-Mappings per client? I can imagine we get rid of them and let
>> them to be completely inherited from "Client Scopes" . My vote is yes.
>> Just afraid if there are some issues with it like:
>> -- backwards compatibility and migration -- But hope that's manageable
>> -- Option "Full Scope Allowed" from role scope mappings -- but that
>> should be solvable too (See below)
>>
>
> Not sure about this one. Client scopes can do it all probably, but I think
> we'd have to address usability here. Say all I want to do is to add a
> protocol mapper to add a single claim to the token for a client then I
> don't want to have to:
>
> * Create scope
> * Add protocol mapper
> * Configure client to set default scope
>
> Then I also have to somehow find the client scopes that are only used by a
> single client.
>
> Yes, I was later thinking too that it is quite problematic. Migration from
> previous versions won't work (without losing some informations).
>
> So then the question remains: How to display on the consent screen the
> protocolMappers and roles, which are defined directly on the client? I was
> thinking about encapsulate them into single scope on the consent screen,
> something like "Client specific" scope or "Client default" scope, or
> something like that?
>

Actually if everything becomes a client scope (aka client template). For
clients that require consents we only store the scopes that was granted.
Then the token is simply update according to the new scope config.


>
>
>>
>>
>> - Consent screen:
>> -- Currently we have set of protocolMappers and set of roles on consent
>> screen. I assume we want to get rid of this and have just single thing:
>> Set of client scopes. Correct?
>> -- If yes, how to proceed with the protocolMappers and Role Scope
>> Mappings, which are defined directly on the client? If we get rid of
>> them (as I mentioned above), we don't have this issue. If we don't get
>> rid of them, we can have something like "Default consent", which
>> encapsulates all the protocolMappers and Role Scope Mappings declared
>> directly on client. WDYT?
>>
>
> Would make a lot of sense to have a single place to define what is shown
> on the consent screen. Client scopes is the place to do it.
>
>
>>
>>
>> - Option "Is Consent Required" and "COnsent Text" on protocol mappers -
>> Do we want to remove those? I think yes.
>>
>
> +1 Not sure how that looks like for backwards compatibility though
>
>
>>
>>
>> - Option "Full Scope Allowed" on clients and option "Scope Param
>> Required" on roles.
>> -- I can imagine we remove both and replace them by having special
>> builtin Client Scope, which will automatically have all the roles (all
>> realm roles and all client roles of all clients) added to itself.
>> -- When new client is created, it will automatically have this builtin
>> Client Scope added to itself - because currently newly created clients
>> also have "Full Scope Allowed" ON by default.
>> -- When new role is created, it will be automatically added to that
>> builtin Client Scope.
>> -- Admin has ability to remove the roles from this Client Scope. This
>> defacto has same meaning like previously "Scope Param Required" flag on
>> role, which is curently used for "offline_acces" role.
>>
>>
>> - I was thinking about creating some UI in admin console for "Scope
>> Evaluating" . Admin will see effective roles and effective
>> protocolMappers based on "scope" parameter he provides. I guess this
>> doesn't have so big priority, but will be good to have IMO.
>>
>
> The builtin client scope sounds like a good idea, the UI to evaluate also.
> Actually I think the UI may be important to be able to easily review how a
> token would look like.
>
>
>>
>>
>> - UserConsentModel - do we remove roles and protocolMappers and replace
>> them instead with Client Scopes? I think yes. Also change the
>> "Applications" tab in account management accordingly and have the same
>> "Client Scopes" like those, which were displayed on consent screen.
>>
>
> +1
>
>
>>
>>
>> - Tokens - I think we still want to keep "Effective" claims and
>> "effective" roles in tokens as is now? At least in first iteration.
>>
>
> Do we perhaps need to introduce revisions for client scopes instead? That
> way we can just track the scope + version for a token.
>
> We talked about revisions before in this document https://docs.google.com/
> document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit in similar
> context.
>
> If I remember correctly, the idea is, that you increase revision number of
> the Client Scope always when you add/update/remove protocolMapper or role
> scope mapping, is it correct? But what you would do when you detect that
> revision number on the token don't match with current revision of scope?
> Automatically reject the token? That means that always when new
> protocolMapper is added or updated, all refresh tokens (and offline) tokens
> are dropped. Sounds quite problematic IMO.
>
> IMO for now, the things in the token can be unchanged and refactoring it
> can be independent on rest of the work IMO. I can try to figure if
> something can be done based on the remaining time in the sprint...
>
> Marek
>
>
>
>>
>> WDYT?
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>