Re: [keycloak-user] Policy enforcer without roles in token

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(a)cuebiq.com&gt; 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(a)redhat.com&gt; > 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(a)cuebiq.com&gt; >> 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(a)cuebiq.com&gt; >>> wrote: >>> >>>> >>>> >>>> On Mon, Nov 11, 2019 at 4:17 PM Pedro Igor Silva <psilva(a)redhat.com&gt; >>>> wrote: >>>> >>>>> >>>>> On Mon, Nov 11, 2019 at 10:40 AM Matteo Restelli < >>>>> mrestelli(a)cuebiq.com&gt; 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(a)redhat.com&gt; >>>>>> 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&gt; 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. >>>>>> >>>>> >>> 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. >