We’ve been reviewing our auth code while chasing some bugs and it’s… quite messy. We currently support a number of external auth mechanisms that we never use ourselves and are very poorly maintained as a result. They never even got mobile support or are usable in the Docker setup.
In order to simplify the auth flows supported in Jitsi going forward we intend to deprecate and remove the following external auth mechanisms:
external JWT in Jicofo
tokenAuthUrl based in Jitsi Meet
Once these are removed the supported auth mechanisms would be:
XMPP (internal, ldap, …)
In our experience (through JaaS for example) keeping JWT on the edge of auth has been sufficient for all scenarios. Users can generate a JWT and then launch Jitsi Meet with it. These tokens can be generated from a custom backend, Firebase, etc.
Before moving forward, we’d like to hear from those of you who might be using any of these today. Would you be ok migrating away from them? What would a reasonable timeline look like?
PS: Ping @Damien_FETIS (you are the only one we know using shibboleth).
You’re right, we’re still using the Shibboleth in Jicofo Auth mechanism and I think there is also one or two other members of this forum that always use this configuration to secure their Jitsi-Meet.
I perfectly understand that we have to move to JWT mechanism. And we already start to work on a configuration with a JWT generator behind a Shibboleth Service Provider.
When do you think, you’ll remove these old auth mechanisms ?
We also use the existing shibboleth auth mechanism and we study a migration to JWT auth based. In fact, we are not familiar with shibboleth auth and we just use it to its support of SSO SAML protocol. Our IDP provider also support some other SSO protocols and we choose to implement our own CAS to JWT auth provider for Jitsi Meet :
We successfully deployed it on our test infrastructure and successfully open a conference by manually provided a JWT in the room URL. However, we would like to make Jitsi Meet automatically redirect user to our auth provider when it want to authenticate a user (it’s actually the behavior with shibboleth).
We tried to use the undocumented tokenAuthUrl, but it seem to have no effect. I tried to read the Jitsi Meet code, but I can’t locate the JitsiMeetJS.util.AuthUtil.getTokenAuthUrl method (called in react/features/authentication/functions.js).
Could you give me some information on how automatic JWT auth redirection work ? In fact, it seem me important to well document this point (and all the JWT auth mechanism) before deprecate other external auth mechanisms.
PS: we are using the latest Jitsi Meet version (2.0.7648).
This will cause a regression (at least) for shibboleth authentication users: Today, when a user creates a conference, he gets a popup telling him that the conference has not started yet and a button “I’m the host”. If he clicks on this button, he will be automatically redirected to the connection interface. It seems to me that this behavior is fine and it will be great if Jitsi Meet keep a solution to implement that.
Is it really not possible to persist the tokenAuthUrl parameter?
It will likely not be there day one (we’ll do this in stages) but we’ll consider it.
Nice and you are right about SSO auth on mobile. Do you think that it’s possible to wait to have something like that (at least on workstation, not for mobile) before removing external auth mechanisms (like sibboleth) ? May be the tokenAuthUrl existing solution could be sufficient for now and we just have to add some doc about this existing solution (even if it should be replaced in the future, we just need to specify it).