Hi Bruno, My plan was to keep policy enforcement in resource servers, Gatekeeper being only responsible for turning permission tickets into RPTs as described in [1]. The reasoning behind this is that is not always possible to deduce resource names and scopes only from HTTP paths and methods. This works well with REST services but not so much with other kinds of APIs such as GraphQL which uses a single endpoint. Does that look reasonable to you ? [1] https://github.com/keycloak/keycloak-documentation/blob/5e4b5a2be332d4012... On Fri, 2019-06-28 at 15:35 -0300, Bruno Oliveira wrote: > Hi Maxime, we will be glad to review new contributions to Gatekeeper. > Although, we need to work together to limit the scope of KEYCLOAK- > 7502[1]. > > My suggestion is to start the discussion on the dev mailing list with > your > plans around this, so we can reach an agreement and add all the > details to > that Jira. Initially, the scope should be limited to what Pedro > already > did for the Node.js adapter[2][3][4]. > > Does it make sense? > > [1] - https://issues.jboss.org/browse/KEYCLOAK-7502 > [2] - https://issues.jboss.org/browse/KEYCLOAK-3334 > [3] - > https://github.com/keycloak/keycloak-documentation/pull/654/files > [4] - https://github.com/keycloak/keycloak-nodejs-connect/pull/142 > > On 2019-06-28, Pedro Igor Silva wrote: > > Thanks, Maxime. I'm adding Bruno to see what he thinks about it. > > > > On Fri, Jun 28, 2019 at 11:25 AM Maxime Suret < > > maxime.suret(a)early-birds.io&gt; > > wrote: > > > > > Hi Pedro, > > > > > > Yes the goal is to make client developement easier and faster by > > > moving > > > all UMA logic inside Gatekeeper. > > > Handling UMA workflows in web applications would require clients > > > to > > > access and modify Gatekeeper's cookies which is quite ugly. > > > This could indeed be a done as part of the feature request you > > > mentioned, even if permission policies would still be enforced by > > > the > > > resource server and not Gatekeeper itself with this solution. > > > If that's ok for you I will go ahead and open a PR referencing > > > this > > > JIRA ticket. > > > > > > Thanks & Best Regards, > > > > > > Maxime > > > > > > > > > On Thu, 2019-06-27 at 10:14 -0300, Pedro Igor Silva wrote: > > > > Hi Maxime, > > > > > > > > Interesting idea. Basically, the GK will do the dirty work for > > > > clients, right? > > > > > > > > We could probably consider having this task as a subtask of > > > > https://issues.jboss.org/browse/KEYCLOAK-10367 ? > > > > > > > > Regards. > > > > Pedro Igor > > > > > > > > On Wed, Jun 26, 2019 at 2:05 PM <maxime.suret(a)early-birds.io&gt; > > > > wrote: > > > > > Hi All, > > > > > > > > > > When Keycloak Gatekeeper gets a 401 response with a > > > > > permission > > > > > ticket > > > > > from upstream, it would be very useful if it could fetch the > > > > > corresponding RPT and retry accessing the upstream resource > > > > > with > > > > > it. > > > > > The RPT would then be placed in the access cookie to avoid > > > > > this > > > > > process > > > > > in subsequent requests. > > > > > That would also be a nice feature to have when using > > > > > gatekeeper as > > > > > a > > > > > forwad signing proxy. > > > > > What do you think ? I am willing to implement this myself. > > > > > > > > > > Thanks ! > > > > > > > > > > Maxime > > > > > > > > > > > > > > > > -- > > > > > > < > > > https://www.eventbrite.com/e/atelier-by-early-birds-x-saint-gobain-distri... -- <https://www.eventbrite.com/e/atelier-by-early-birds-x-saint-gobain-distri...