10 a.m.
On 22/02/18 16:32, luke(a)code-house.org wrote:
Hey,
At the beginning, I would like to say thank you, for delivering such great software, and
also people who read this message for handling community support. :-)
I come into key cloak because I do need two functionalities of it - oidc provider and
also identity broker. I do integrate with services which have predefined set of scopes. My
application can request multiple scopes such "patient/*.write” (write data related to
patient), however user or system where authentication takes place, may decide to grant
lower access than requested.
For example above patient write scope request might be constrained to
"patient/*.read" or even subset of that "patient/Patient.read” (patient
demographics). Reason why it might happen depends on few things - because user who decides
to unmark these on consent page or it might not be allowed by system. In second case user
will not be even asked about giving such permission to his data.
From logical point of view, as long as authorisation request ends up with token grant,
these are still proper tokens which application must handle. Question is - is such use
case is supported by Keycloak?
Also, how should I map such wildcard scopes in keycloak?
Those are interesting
usecases.
At this moment, we don't have support for "unmark" specific consents on
consent screen. Maybe it's something, which will be good to support. I
know Facebook has some support for it (some consents are mandatory and
can't be unchecked on the consent screen. Some are optional and can be
unchecked). This may be nice to have. Feel free to create JIRA.
For the second part, I am working on refactoring of scope parameter
support. This will allow some more flexibility - especially you will be
able to map more roles into single client scope (which defacto means,
single value of scope parameter and single item on consent screen for
whole group of roles). Maybe it's something, which would help you with
the usecase? In other words, there won't likely be support for regexes
(at least in first stage, which should be finished in few weeks), but
maybe your usecase can be addressed with it still.
Second use case, which I have, is similar to first one. Main difference is that it must
be implemented on key cloak authorisation part - when user application requests access
token, it sends two scopes, lets call them “user" and "patient”. Because
application doesn’t know actual permissions of the user, it can not decide which scopes
should be used. We theoretically could work around that with two login pages resulting in
different scope requests. However, our intention is to implement this on keycloak side -
based on our own logic we will know what is role of given user and which scope is
permitted. Biggest question - which extension point, if any available, we could use for
that?
That's also interesting usecase.
We don't have it OOTB, but I think that there is a way to "plug" your
own logic for it. I think you can do custom requiredAction
implementation, which will remove some values from scope parameter based
on the actual permissions, which authenticated user have and hence the
roles won't be shown on the consent screen at all then.
But note that I am working on refactoring of this part, so if you do
some "extension" of your own at current Keycloak, you might need to
refactor it later. Anyway, feel free to create JIRA for the better
support of this usecase OOTB.
I suggest to keep an eye on our MLs, hope there will be something about
better support of client scopes (scope parameter) very soon. I would be
curious for feedback.
Thanks,
Marek
Kind regards,
Łukasz
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user