On Mon, Nov 11, 2019 at 10:40 AM Matteo Restelli <mrestelli(a)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 ...
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 ...
- 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 ...
- 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.
Thank you again,
Matteo
On Mon, Nov 11, 2019 at 1:20 PM Pedro Igor Silva <psilva(a)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(a)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(a)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.