[keycloak-user] Authorization returning less scopes than requested

[Marek Posolda]

On 22/02/18 16:32, luke at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user