Intent to deprecate and remove: external auth mechanisms

Developers
1

Hey all!

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
  • shibboleth

Once these are removed the supported auth mechanisms would be:

  • XMPP (internal, ldap, …)
  • JWT

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?

Cheers!

PS: Ping @Damien_FETIS (you are the only one we know using shibboleth).

2 Likes
2

From what I understand from some posts, some users use “external JWT” with “guest virtualhost” to get “wait for host” message on UI.

1 Like
3

Good point, thanks for raising it.

4

For a deployment that support only JWT auth only (no guest users, and no XMPP auth), what would a user journey look like if they land on the site without a token?

I believe at present the login dialog is show, which we found to be confusing to users.

For now we abuse the tokenAuthUrl option to redirect them to a static auth error page. Would be good to have a proper solution if we plan to drop tokenAuthUrl.

5

Good point. We have been thinking about passing some metadata so we know the auth type and can better react to it.

1 Like
6

Hi @saghul,

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 ?
Regards,
Damien

7

Good to hear!

We haven’t talked about when to do it yet. How would in 2 stable releases sound? We’d deprécate it in the next and remove it in next-next. Thoughts?

8

Hi @saghul,
That’s a fine roadmap for the Big Auth Refactoring.

We’ve made some test to deploy a simple solution for the SAML to JWT part : GitHub - Renater/Jitsi-SAML2JWT: A projet to easily use SAML authentification with JItsi-Meet JWT authentification.
And with the tokenAuthUrl parameters it works fine.

We are ready to test the future release.

Regards,
Damien.

9

That is great news!

10

If you’d like, I think having it linked here would be useful to others: Third-Party Software | Jitsi Meet

1 Like
11

It’s a very good idea.
I have just created a PR for this.

Regards,
Damien.

1 Like
12
13

Hello,

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).

14

The plan is to NOT support this use case. Applications need to supply a token in the URL or depending on how the server is configured will get an error when trying to join.

15

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?

16

That has never worked on mobile, for instance. The sibboleth usage has been anecdotal at best, that’s why we are trying to simplify things here.

Now, one thing I realized is that, in an SSO scenario it’s true we need something like that.

It will likely not be there day one (we’ll do this in stages) but we’ll consider it.

17

Blockquote
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).

18

I’m not sure, the reason for this discussion is for us to refactor and consolidate some connection related code, not sure we can keep this around while doing that, but I’ll try.

19

@saghul I appreciate the heads up on changes like this. We are using straight JWT as described here and even though we are not using it currently, fwiw I always found the tokenAuthUrl option useful.

I have 2 questions:

  1. Now that some time has passed since the original post, do have a (high-level) time line for when these changes may happen?

  2. Regarding JWT… When you say:

You’re talking about joining a meeting using https://example.com/angrywhalesgrowhigh?jwt=eyJhbR...ga5W4 as described here?

20

@saghul, what do you think about passing some data as querystrings to the authError page?

When user has not a valid token, she is redirected to authError.html. If some data (such as room, jwt, etc) can be accessible in authError page then it may be possible to add some custom logic.