Unfortunately, this is not what I would call a how-to or a good tutorial. Especially, those both plugins built upon the Prodody plugin JWT token authentication Prosody plugin which must be installed first. Moreover, the instruction describe how a JWT token has to look like and refer to RFC 7519 for a specification of those tokens, but of course this does not explain where these tokens come from, i.e. some kind of “authenticator” or token provider.
The documentation is fine for developers who already know how to setup all components and want to contribute, but the documentation is not a how-to or tutorial for administrators who want deploy such a setup. My apologies, but this is like pointing someone to RFC 2616 if one asks how to setup an Apache web server.
To my understanding the architecture/whole picture consists of the following components:
- Prosody with the plugin mod_token_auth, token_affiliation and token_owner_party,
- a backend which stores user accounts and privileges (LDAP, SQL database, etc.), and
- some kind of “authenticator” aka “token provider” which receives authentication requests from Prosody, queries the backend, generates tokens and serve those tokens as a respond to Prodody.
So the first question is: What application can be used as “authenticator”/“token provider”? Is there any de-facto standard application already packed in typical linux distributions (like Apache and nginx for web server, postfix for smtp server, etc.)?
IMHO, a good tutorial/howt-o would start from a standard installation of Jitsi as a baseline and cover the following topics:
- Installation of the Prosody plugins (OK, that’s mostly in the readme)
- Installation of the backend (LDAP or similar)
- Installation of the “authentication service”/“token provider”
- Configuration of all these three components such that they interact with each other, especially configuration of the shared secrets such that these components can speak with each other
- Basic testing/debugging to check if the components actually do speak with each other or if something went wrong
Don’t get me wrong: You guys do a great job in developing Jitsi for free. That’s fantastic and unfortunately I don’t have the time to contribute which is a shame. Also, I perfectly know that nobody likes to write documentation, especially if it is unpaid. Coding is just so much more fun. But, if there is no good documentation/howto, then state so frankly and honestly. Nobody will be hurt by that. However, pointing administrators to some more or less internal developer documentation is somewhat strange.