From Keycloak to proper AuthN and AuthZ

[bellebaum]

This Issue fits into all your categories, hence here without a template :)

The problem

This project seems to try to rely on Keycloak in a way which is probably not intended.
This is creating anything from inconveniences to bugs with the potential to be security vulnerabilities.

For example, there is an option that not everyone should be able to add a server, yet the option to do so is only hidden in the GUI, but no proper access control is performed on the server.

Also people seem to struggle with the integration of this project with existing SSO infrastructures, since some of them use authorization servers other than Keycloak (which may not even have the concept of a group) or have their own heavily customized Keycloak instances.

The broader picture

What this project wants to achieve is the authorization of actions performed by authenticated (to the application) users.

The ways to do this (going via standards) are called OAuth 2.0 and OpenID Connect respectively.
Both are supported by Keycloak (among others) and indeed used in this project, although incorrectly.

The idea behind these protocols is to centralize authorization and authentication at a specialiced service, called the authorization server (in the case of OpenID Connect, which is an extension of OAuth 2.0, it is also called the OpenID Provider (OP)).
The API endpoints to be secured are called resource servers. The (in-browser or on-server) application is called a client.

So how is it supposed to work?

OAuth 2.0

The client wants to access the resource server on behalf of a user. To do this, it has to request a so-called access token from the authorization server first. This access token has an attached scope, which represents the access rights of this token.

In an OAuth 2.0 Authorization Code Flow (the most prominent way to get an access token, and the one used here), the client redirects the user to the authorization server's authorization_endpoint, passing along a series of parameters like its client_id and the requested scope. The authorization then does stuff (usually authenticating the user and asking them for consent to give these access rights to the client) before redirecting the user back to the client with an authorization_code, which the client may then exchange for an access token at the authorization server's token_endpoint (This may seem convoluted, but in some cases this allows the client to authenticate in the process as well if the authorization server demands it).

With the access_token in the response, the client can now access the resource server, which checks the token and its scope (which is nowadays usually denoted in the token itself if it is a JWT, otherwise the resource server can request more information about the token at the authorization server), and based on that information alone decides whether to grant the request.

Note: There was no mention of a group or anything like that in here. The way it is supposed to work in Keycloak is to organize users into groups, then instruct the authorization server to grant or deny certain scopes based on whether the user is in a particular group.

OpenID Connect

Think all of the above, but whenever the client includes the scope openid in its request, it wants to have a JWT specifying how and when exactly the authorization server identified a user (and who that user is, given as a stable identifier called sub for later reference), as well as access to a special OAuth protected resource called the userinfo_endpoint, at which it may get information about the user, like their preferred username or their birth date.

The proposal

In short: Separate Keycloak from the project.

That is, make sure the scopes to be required to access certain API endpoints are configurable (e.g. jitsi_admin for basic access, jitsi_admin_configuration to change anything), then request them all the scopes when making a user log in, and for the API ensure that the granted scopes (and only the scopes!) are used for access control.

This way, admins can freely integrate this project into their existing infrastructure, still using their preferred method to grant and deny rights, using whichever authorization server they are using, and not having to maintain another one just because this project was tightly integrated with one.

[holema]

Hello @bellebaum,

Can you please write me an email to [email protected] to discuss this feature, because I saw that you are from the AISEC. :)

Best regards

[holema]

Hello @bellebaum,

propably you are interested in our jitsi-admin community talk we are doing every two weeks on thursday at 06pm.
The next talk is tomorrow. You can sign up for the call at: http://jitsi-admin.de/subscribe/self/4754e33d3ee9a6c40a2bf04ffa1528c7.
There we can discuss your feature and how we can work with this.