On 9 February 2018 at 14:30, Marek Posolda <mposolda(a)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?
- 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?
- 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.
- 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.
WDYT?
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev