Jetty servlet location /login/ - 404 not found with shibboleth authentication

Dear community,

we want to implement shibboleth authentication using apache as the webserver.
The shibboleth part is working, the client gets authenticated by the IDP.

When I get redirected to
I get a 404 not found page from Jetty.

Apache config should be fine since shibboleth is working and apache gets a response from the proxied Jetty.

Could you please help troubleshoot this? I will provide the necessary logs.

Turned FINE logging on and jicofo.log shows this:

Jicofo 2020-03-06 11:42:26.018 FINE: [26] org.eclipse.jetty.server.Server.handle() REQUEST GET /login/ on HttpChannelOverHttp@1c7141dd{r=1,c=false,c=false/false,a=DISPATCHED,uri=//{ourdomain}/login/?machineUID=1ac27ccdf7d7c1b98414b977a72bcc70&room=nervousgorillasfragmenthysterically@conference.{ourdomain}&close=false,age=7}
Jicofo 2020-03-06 11:42:26.018 FINE: [26] org.eclipse.jetty.server.handler.ContextHandler.doScope() scope null||/login/ @ o.e.j.s.ServletContextHandler@70de6594{/,null,AVAILABLE}
Jicofo 2020-03-06 11:42:26.019 FINE: [26] org.eclipse.jetty.server.handler.ContextHandler.doScope() context=||/login/ @ o.e.j.s.ServletContextHandler@70de6594{/,null,AVAILABLE}
Jicofo 2020-03-06 11:42:26.019 FINE: [26] org.eclipse.jetty.servlet.ServletHandler.doScope() servlet ||/login/ -> org.glassfish.jersey.servlet.ServletContainer-5e6a026@15842c8b==org.glassfish.jersey.servlet.ServletContainer,jsp=null,order=-1,inst=true,async=true
Jicofo 2020-03-06 11:42:26.020 FINE: [26] org.eclipse.jetty.servlet.ServletHandler.doHandle() chain=null
Jicofo 2020-03-06 11:42:26.055 FINE: [26] org.glassfish.jersey.server.ServerRuntime$Responder.mapException() WebApplicationException (WAE) with no entity thrown and no ExceptionMappers have been found for this WAE. Response with status 404 is directly generated from the WAE. HTTP 404 Not Found
at org.glassfish.jersey.server.ServerRuntime$
at org.glassfish.jersey.internal.Errors$
at org.glassfish.jersey.internal.Errors$
at org.glassfish.jersey.internal.Errors.process(
at org.glassfish.jersey.internal.Errors.process(
at org.glassfish.jersey.internal.Errors.process(
at org.glassfish.jersey.process.internal.RequestScope.runInScope(
at org.glassfish.jersey.server.ServerRuntime.process(
at org.glassfish.jersey.server.ApplicationHandler.handle(
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(
at org.glassfish.jersey.servlet.WebComponent.service(
at org.glassfish.jersey.servlet.ServletContainer.service(
at org.glassfish.jersey.servlet.ServletContainer.service(
at org.glassfish.jersey.servlet.ServletContainer.service(
at org.eclipse.jetty.servlet.ServletHolder.handle(
at org.eclipse.jetty.servlet.ServletHandler.doHandle(
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(
at org.eclipse.jetty.servlet.ServletHandler.doScope(
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(
at org.eclipse.jetty.server.handler.ContextHandler.doScope(
at org.eclipse.jetty.server.handler.ScopedHandler.handle(
at org.eclipse.jetty.server.handler.HandlerList.handle(
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
at org.eclipse.jetty.server.Server.handle(
at org.eclipse.jetty.server.HttpChannel.handle(
at org.eclipse.jetty.server.HttpConnection.onFillable(
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
at org.eclipse.jetty.util.thread.QueuedThreadPool$
Jicofo 2020-03-06 11:42:26.064 FINE: [26] org.eclipse.jetty.server.HttpChannel.sendResponse() sendResponse info=null content=DirectByteBuffer@6cc7b8f6[p=0,l=323,c=32768,r=323]={<<<\n\n<me…/body>\n\n>>>\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00…\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00} complete=true committing=true callback=Blocker@13c209db{null}
Jicofo 2020-03-06 11:42:26.064 FINE: [26] org.eclipse.jetty.server.HttpChannel.commit() COMMIT for /login/ on HttpChannelOverHttp@1c7141dd{r=1,c=true,c=false/false,a=DISPATCHED,uri=//meet.{ourdomain}/login/?machineUID=1ac27ccdf7d7c1b98414b977a72bcc70&{ourdomain}&close=false,age=53}
404 Not Found HTTP/1.1

No help from our side, but we are experiencing exactly the same. I have used the stable version (Jicoco 508) and based on this issue, we upgraded to nightly (524). The error persists (and the redirect URL seems to be mangled with some commented out stuff).

I am now trying to downgrade to an older version of all packages from here: (the 2019-08-22 releases)

I will keep you posted

Downgrading worked, but now I’m stuck with

Problem accessing /login/. Reason:

    Attribute 'mail' not provided - check server configuration

and that was fixed by adding shib_request_use_headers on; in the location /login block in the nginx conf

Dear Jens,

many thanks for your comments :slightly_smiling_face: I will try downgrading as well.

I can confirm that downgrading to 2019-08 debian packages worked.

Here is the apache config for shibboleth in case someone is looking for it.
<Location /login>
AuthType shibboleth
ShibRequestSetting requireSession true
ShibUseHeaders On
Require valid-user
SetHandler shib
ProxyPass http://localhost:8888/login
ProxyPassReverse http://localhost:8888/login

Hi, I’m also facing a 404 after going back to /login. What do you mean by dowangrade to 2019-08. Which version exactly? (I have latest: 1.0-508-1)

I see, using, it means:

apt install jicofo=1.0-481-1 jitsi-meet=1.0.3936-1 jitsi-videobridge=1124-1 jitsi-meet-web=1.0.3577-1 jitsi-meet-web-config=1.0.3577-1 jitsi-meet-prosody=1.0.3577-1

I confirm 404 fixed with downgrade, I now have missing mail attribute, will look deeped in my SP configuration …

We needed to add shib_request_use_headers on; in the nginx config.

In the meantime we are on nightly in order to have MUC enabled scalable videobridges (Perfomance is currently more important than authentication)


Oh gawd, I wish I had found this post on Thursday afternoon. After the downgrade (on Sunday afternoon) it seems to be working again.

Thanks for the downgrade tip!


not sure, if this is the same problem, but I get a 404 on /login after authenticated by our Shibboleth IDP too.

My nginx config:

server {
    listen 443 ssl;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers  .....

    add_header Strict-Transport-Security "max-age=31536000";

    ssl_certificate /etc/nginx/ssl/testdomain_com.crt;
    ssl_certificate_key /etc/nginx/ssl/testdomain_com.key;

    root /usr/share/jitsi-meet;
    ssi on;
    index index.html index.htm;
    error_page 404 /static/404.html;

    location = /config.js {
        alias /etc/jitsi/meet/;

    location = /external_api.js {
        alias /usr/share/jitsi-meet/libs/external_api.min.js;

    #ensure all static content can always be found first
    location ~ ^/(libs|css|static|images|fonts|lang|sounds|connection_optimization|.well-known)/(.*)$
        add_header 'Access-Control-Allow-Origin' '*';
        alias /usr/share/jitsi-meet/$1/$2;

    # BOSH
    location = /http-bind {
        proxy_pass      http://localhost:5280/http-bind;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;

    location ~ ^/([^/?&:'"]+)$ {
        try_files $uri @root_path;

    location @root_path {
        rewrite ^/(.*)$ / break;

    # Shibboleth

    location = /shibauthorizer {
      include fastcgi_params;
      fastcgi_pass unix:/var/run/shibboleth/shibauthorizer.sock;

    location /Shibboleth.sso {
      include fastcgi_params;
      fastcgi_pass unix:/var/run/shibboleth/shibresponder.sock;

    location /shibboleth-sp {
      alias /usr/share/shibboleth/;

    # Login location where Jicofo servlet is running

    location /login {
      shib_request_use_headers on;
      more_clear_input_headers 'Variable-*' 'Shib-*' 'Remote-User' 'REMOTE_USER' 'Auth-Type' 'AUTH_TYPE';
      more_clear_input_headers 'displayName' 'mail' 'persistent-id';
      shib_request /shibauthorizer;

system is ubuntu 18.04 LTS:

ii  jitsi-meet                            1.0.4101-1                                      all          WebRTC JavaScript video conferences
ii  jitsi-meet-prosody                    1.0.3729-1                                      all          Prosody configuration for Jitsi Meet
ii  jitsi-meet-web                        1.0.3729-1                                      all          WebRTC JavaScript video conferences
ii  jitsi-meet-web-config                 1.0.3729-1                                      all          Configuration for web serving of Jitsi Meet
ii  jitsi-videobridge                     1126-1                                          amd64        WebRTC compatible Selective Forwarding Unit (SFU)
ii  nginx                                 1.16.1-1~bionic                                 amd64        high performance web server
ii  nginx-module-headersmore              1.16.1-1~bionic                                 amd64        nginx headersmore dynamic module
ii  nginx-module-shibboleth               1.16.1-1~bionic                                 amd64        nginx shibboleth dynamic module

Setting shib_request_use_headers on; didn’t help in my case.

Any ideas?


looks like it is the same problem. I created to track it


I downgraded only jicofo deb package to version 1.0-481-1, not the other jitsi debian packages like jitsi-meet, jitsi-meet-prosody, jitsi-meet-web*, jitsi-videobridge. Would that be stable or do I have to downgrade each of them?