Add authorization services support to Gatekeeper

[abstractj]

What:

As a Gatekeeper developer, I want to enable a policy enforcer to my service or application so that I can enforce access to protected resources using fine-grained permissions.

This issue is all about enabling policy-enforcer configuration, as we have in other adapters, to Gatekeeper.

Reference:

• KEYCLOAK-7502 - Add authorization services support to Gatekeeper

[p53]

i checked how it is done for application adapters and i think it is quite static, ideally there would be some context providers which would automatically generate body of request for permission ticket from parameters of incoming HTTP request e.g. keycloak_http_method_context_provider() would generate permission ticket request with this body:

'[
  {
    "resource_id": "{resource_id}",
    "resource_scopes": [
      "GET"
    ]
  }
]'

as request_id is passed in permission ticket it should be gathered from keycloak server e.g. by this request:

To query resources given an uri, send an HTTP GET request as follows:

http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set?uri=/api/alice

and if these providers would be stackable/additive e.g. something like:

authorized_context.add(keycloak_http_method_context_provider)
authorized_context.add(keycloak_http_headers_context_provider)

keycloak.create_permission_ticket(authorized_context)

or something like that

etc...

probably it would need also some caching to maintain some acceptable performance

[stianst]

There's one thing adding support for UMA 2, but not sure that fully covers Keycloak authorization services.

We also probably want the authz layer to be extensible I can see at least the following options in the future:

• Basic DSL built into Louketo
• WebHook - some clean/simple webhook API to plugin something external
• UMA 2
• Custom Go
• Keycloak Authorization Services - not sure if this is needed or we can do what we need to through UMA 2, or even supporting the Louketo defined WebHook API in Keycloak may be better

[p53]

https://github.com/grepplabs/kafka-proxy, maybe this could be inspiration

[pedroigor]

@stianst I would not consider UMA 2 for now. It solves a very specific set of use cases that are beyond API/HTTP security.

Regarding Authorization Services, it is all about implementing a PEP that talks with Keycloak (PDP) to obtain a decision. Not different than what we have in our Java Adapters or NodeJS. In fact, the WebHook can also be used to integrate with Authorization Services, as long as we provide the endpoint OOTB leveraging our policy model to process the payload.

The DSL idea is interesting and focusing on API/HTTP security should allow us to provide a more specific DSL for HTTP-based resources. However, that would also mean implementing some components to understand this DSL and process the conditions/policies (access control mechanisms) accordingly.

We could even have some form of switch that decides whether or not a decision should be made locally or externally by a PDP/Webhook. The use case would be that for certain HTTP resources you may want some basic role, or group, or user access enforcement. But for others, you may want more rich and contextual access enforcement.

There is also the possibility to have Louketo fetch policies using the DSL from some external service. If in Kubernetes, that would help Louketo obtain these policies from CRDs. Or just allow fetching these DSLs from some external service. That would make things more dynamic too and leverage centralized authorization to some degree as these policies could be managed from a central location.

[stianst]

To plugin Authorization Services with Gatekeeper we should define the simpler Authorization Webhook API that is then implemented by both Keycloak and Gatekeeper. This API will be simple enough that anyone can implement it in a different PDP, which makes it usable outside of just Gatekeeper.

For the DSL (although thinking about it I would rather call it a Policy Config/Definition, as we don't want to make a full blown DSL) approach it really is about Gatekeeper supporting what it does now, but defined in the standard Policy Config file that Keycloak is also able to read. So not much more than mapping the config file to what it already implements.

[pawneeranger]

Is there anybody working on that feature right now ?

[sjhr007]

Is this feature available in keycloak gatekeeper?

[abstractj]

@pawneeranger nobody is working on this feature, please see https://github.com/louketo/louketo-proxy/issues/683

@sachinjohar2 no, this feature is not available on Gatekeeper and we don't have any plans to implement it.