[keycloak-user] Policy enforcer without roles in token

Thu Nov 14 12:57:28 EST 2019

Sure, please leave your comments in the PR or
https://issues.jboss.org/browse/KEYCLOAK-10731.

Thanks.

On Wed, Nov 13, 2019 at 5:16 AM Matteo Restelli <mrestelli at cuebiq.com>
wrote:

> Yeah, also for me it could be fine to introduce this feature with some
> sort of a flag (from the KC GUI or directly in the KC adapter) to control
> the desired behaviour. So, what about your colleagues? What do they think
> about that?
> If you want i can open a Jiira issue about that or i can comment the
> previously closed PR. It could be fine for you?
>
> Thank you again,
> Matteo
>
> On Tue, Nov 12, 2019 at 8:04 PM Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> You are right. But today the token is the primary source of the identity
>> (and access context).
>>
>> From a KC perspective, it does not make much difference as you said.
>> Especially because in most cases, the primary (primary from an authz
>> perspective) claims included in the token during authentication don't
>> represent user consent or anything alike that could potentially tie the
>> access context to the session.
>>
>> If this feature can just be enabled/disabled so that users decide what
>> they want to do, for me it is fine.
>>
>> On Tue, Nov 12, 2019 at 6:14 AM Matteo Restelli <mrestelli at cuebiq.com>
>> wrote:
>>
>>> Hi Pedro,
>>> Sorry for this second email. So the PR has been closed due to the fact
>>> that it's necessary to validate only token contents. But, what about
>>> javascript policies? I mean, if i have the following use case:
>>>
>>> An user is trying to make a GET to /organizations/1234/reports/1 path.
>>> To access the following policies must pass (AND condition):
>>> - An user must have the role "blabla" (role policy)
>>> - An user must belong to a the group 1234 (javascript policy, we
>>> validate the path against the fact that he belongs to a group, since we're
>>> modeling organizations as groups in Keycloak)
>>>
>>> I'm validating both contents in the token and both something "external".
>>> So it's not the same case of validating roles directly reading the database?
>>>
>>> Thank you,
>>> Matteo
>>>
>>>
>>> On Mon, Nov 11, 2019 at 4:47 PM Matteo Restelli <mrestelli at cuebiq.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Nov 11, 2019 at 4:17 PM Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Mon, Nov 11, 2019 at 10:40 AM Matteo Restelli <mrestelli at cuebiq.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Pedro,
>>>>>> thank you for your reply.
>>>>>> No, i wasn't the one who requested the feature, anyway i'm still
>>>>>> interested into it. Our use case includes several microservices (which
>>>>>> represents modules of our PaaS) which performs authorization checks against
>>>>>> realm based roles. Every microservices has each own client containing its
>>>>>> authorization checks.
>>>>>>
>>>>>
>>>>> Interesting, another use-case then ...
>>>>>
>>>>
>>>> Yeah, we've separated authorization inside each backend client, in
>>>> order to better separate authorization requirements. Each microservice will
>>>> then validate and refer to its own authorization requirements. The frontend
>>>> client, instead, is a single public client which receives the complete
>>>> lists of roles (since they're defined at realm level)
>>>>
>>>>
>>>>>
>>>>>
>>>>>> Besides the PR (which is really really interesting and i hope it will
>>>>>> be included in further releases), what are your recommendations to reduce
>>>>>> the access token size? I'm asking this because in some browsers there are
>>>>>> limits (4KB) about cookies & headers length. I can imagine those solutions:
>>>>>>
>>>>>> - Keep the token "light" and perform a token exchange into our
>>>>>> gateway once we receive the token from the single page application, in
>>>>>> order to retrieve a new token with all the realms roles associated to the
>>>>>> user
>>>>>>
>>>>>
>>>>> The price you pay is a round-trip to the server. But it works ...
>>>>>
>>>>
>>>> Yeah and i want to completely avoid that, in order to avoid
>>>> to be "bottlenecked" by Keycloak
>>>>
>>>>
>>>>>
>>>>>
>>>>>> - Use some particular mode of the adapter which will do the necessary
>>>>>> to retrieve the roles (but i can't find something like that in the docs)
>>>>>>
>>>>>
>>>>> Roles are gathered from the token, always ...
>>>>>
>>>>
>>>> Yeah, i just saw it debugging the keycloak code locally... :(
>>>>
>>>>
>>>>>
>>>>>
>>>>>> - Use RPT? Once the gateway receives the access token, perform the
>>>>>> RPT request to retrieve a token with all the permissions for the particular
>>>>>> client
>>>>>>
>>>>>
>>>>> The beauty of the RPT is that the permissions should be enough as the
>>>>> server already granted them based on the state of the current session.
>>>>> Resource-based permissions also decouple applications from access control
>>>>> mechanisms so that you have more flexibility and control over the policies
>>>>> that govern access to your resources.
>>>>>
>>>>> It should not be seen as *the* solution for large tokens though ...
>>>>>
>>>>>
>>>>>> - Something else unknown to us? :)
>>>>>>
>>>>>
>>>>> Maybe use a mapper or don't include tokens by default in your token.
>>>>> So that your client requests what he needs (yeah, more coupling between
>>>>> your clients + resource servers). The client scopes functionality is very
>>>>> interesting in this context given that you can set-up a scope that spans
>>>>> multiple roles, on a per-application basis.
>>>>>
>>>>>
>>>>>>
>>>>>> Have you ever faced this kind of problem?
>>>>>>
>>>>>
>>>>> Another user reported a similar requirement that originated that PR. I
>>>>> see value in having this as it helps the "decouple authorization from your
>>>>> applications* story.
>>>>>
>>>>
>>>> Yeah me too. I know that the main idea is to validate only what is
>>>> contained in the token, but maybe it could be possible to introduce some
>>>> other feature including this possibility...
>>>>
>>>> Thank you again,
>>>> Matteo
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Thank you again,
>>>>>> Matteo
>>>>>>
>>>>>> On Mon, Nov 11, 2019 at 1:20 PM Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> We had a PR [1] for addressing this use case but it was closed due
>>>>>>> to not enough quorum to support the changes.
>>>>>>>
>>>>>>> While we should keep policy enforcement based on the state carried
>>>>>>> by tokens, I see as an improvement to also allow users, on a per-use case
>>>>>>> basis, to fetch roles directly from the realm instead, even if they are not
>>>>>>> available in the token.
>>>>>>>
>>>>>>> I can't remember now, but I'm wondering if was you that first
>>>>>>> requested this so I ended up working on these changes?
>>>>>>>
>>>>>>> Regards.
>>>>>>> Pedro Igor
>>>>>>>
>>>>>>> [1] https://github.com/keycloak/keycloak/pull/6163
>>>>>>>
>>>>>>> On Mon, Nov 11, 2019 at 5:43 AM Matteo Restelli <
>>>>>>> mrestelli at cuebiq.com> wrote:
>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>> we’re experiencing issues about JWT access_token size and we were
>>>>>>>> planning
>>>>>>>> to remove the “roles” claim as a default, so to remove the claim
>>>>>>>> from the
>>>>>>>> access_token. Once we do that, the KC adapter / policy enforcer
>>>>>>>> returns a
>>>>>>>> 403. So at this point, does the access_token must have the roles
>>>>>>>> inside it?
>>>>>>>> Or it’s another problem which is giving us the 403?
>>>>>>>>
>>>>>>>> Thank you!
>>>>>>>> Matteo
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Like <https://www.facebook.com/cuebiq/> I Follow
>>>>>>>> <https://twitter.com/Cuebiq>I Connect
>>>>>>>> <https://www.linkedin.com/company/cuebiq>
>>>>>>>>
>>>>>>>>
>>>>>>>> This email is reserved
>>>>>>>> exclusively for sending and receiving messages inherent working
>>>>>>>> activities,
>>>>>>>> and is not intended nor authorized for personal use. Therefore, any
>>>>>>>> outgoing messages or incoming response messages will be treated as
>>>>>>>> company
>>>>>>>> messages and will be subject to the corporate IT policy and may
>>>>>>>> possibly to
>>>>>>>> be read by persons other than by the subscriber of the box.
>>>>>>>> Confidential
>>>>>>>> information may be contained in this message. If you are not the
>>>>>>>> address
>>>>>>>> indicated in this message, please do not copy or deliver this
>>>>>>>> message to
>>>>>>>> anyone. In such case, you should notify the sender immediately and
>>>>>>>> delete
>>>>>>>> the original message.
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>>
>>>>>> Like <https://www.facebook.com/cuebiq/> I Follow
>>>>>> <https://twitter.com/Cuebiq>I Connect
>>>>>> <https://www.linkedin.com/company/cuebiq>
>>>>>>
>>>>>> This email is reserved exclusively for sending and receiving messages
>>>>>> inherent working activities, and is not intended nor authorized for
>>>>>> personal use. Therefore, any outgoing messages or incoming response
>>>>>> messages will be treated as company messages and will be subject to the
>>>>>> corporate IT policy and may possibly to be read by persons other than by
>>>>>> the subscriber of the box. Confidential information may be contained in
>>>>>> this message. If you are not the address indicated in this message, please
>>>>>> do not copy or deliver this message to anyone. In such case, you should
>>>>>> notify the sender immediately and delete the original message.
>>>>>>
>>>>>
>>> Like <https://www.facebook.com/cuebiq/> I Follow
>>> <https://twitter.com/Cuebiq>I Connect
>>> <https://www.linkedin.com/company/cuebiq>
>>>
>>> This email is reserved exclusively for sending and receiving messages
>>> inherent working activities, and is not intended nor authorized for
>>> personal use. Therefore, any outgoing messages or incoming response
>>> messages will be treated as company messages and will be subject to the
>>> corporate IT policy and may possibly to be read by persons other than by
>>> the subscriber of the box. Confidential information may be contained in
>>> this message. If you are not the address indicated in this message, please
>>> do not copy or deliver this message to anyone. In such case, you should
>>> notify the sender immediately and delete the original message.
>>>
>>
> Like <https://www.facebook.com/cuebiq/> I Follow
> <https://twitter.com/Cuebiq>I Connect
> <https://www.linkedin.com/company/cuebiq>
>
> This email is reserved exclusively for sending and receiving messages
> inherent working activities, and is not intended nor authorized for
> personal use. Therefore, any outgoing messages or incoming response
> messages will be treated as company messages and will be subject to the
> corporate IT policy and may possibly to be read by persons other than by
> the subscriber of the box. Confidential information may be contained in
> this message. If you are not the address indicated in this message, please
> do not copy or deliver this message to anyone. In such case, you should
> notify the sender immediately and delete the original message.
>