[keycloak-dev] Scope parameter support
Marek Posolda
mposolda at redhat.com
Tue Feb 13 07:10:56 EST 2018
Created document
https://docs.google.com/document/d/1Ht6cRPdFFUOTXtYNCe2UJknh0qo3RBO9F9nsInLBJrc/edit?usp=sharing
. Anyone should be able to comment.
I've added P1 to the points, which I believe should be done in iteration
1 and which I think we are in agreement. Others with P2 or P3 can be
done in later iteration (EG. Groups support) or even postponed to
future. This contains especially things, where we didn't reach the 100%
agreement. Those mostly have "maybe" flag on them, so it's not even sure
if we do them or if the way I described will be used to implement them.
Marek
On 12/02/18 18:17, Stian Thorgersen wrote:
>
>
> On 12 February 2018 at 14:57, Marek Posolda <mposolda at redhat.com
> <mailto: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
>> <mailto: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
> <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
>> <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>
More information about the keycloak-dev
mailing list