"FastCGI Shibboleth responder should only be used for Shibboleth protocol requests." when using handlerSSL="true"

[dcale]

Is this plugin compatible with shibboleths2.xml's handlerSSL="true" ? because as soon as I activate this all fastcgi requests fail...

[davidjb]

Do you mean handlerSSL on the <Sessions> element within shibboleth2.xml? If so, there should be no problem. My config looks like this:

 <Sessions lifetime="28800" timeout="3600" checkAddress="false" 
                  relayState="ss:mem" handlerSSL="true"
handlerURL="/Shibboleth.sso"> 

Fwiw, handlerSSL="true" also appears to default to true (https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions), so without that specified in your configuration you should end up with true as its value anyway.

Without much more to go on, check your nginx configuration that handles /Shibboleth.sso (or how you've named it). Generally, the config at https://github.com/nginx-shib/nginx-http-shibboleth/blob/master/CONFIG.rst#configure-nginx is sufficient with a default nginx install, but you may need to check that your include fastcgi_params; is passing data correctly. In short, snsure nginx is passing the correct FastCGI params to let the the Shibboleth FastCGI applications that it is running over HTTPS (and other relevant params for the request).

[KirilKovachev]

Hi, I'm getting the same("FastCGI Shibboleth responder should only be used for Shibboleth protocol requests.") when trying to access Shibboleth.sso/Metadata and handlerSSL is"true" in the NGINX error log the message logged is: [error] 15744#0: *67 FastCGI sent in stderr: "shib: doHandler failed to handle the request" while reading response header from upstream For location location /Shibboleth.sso I have only the: "include fastcgi_params;" directive entered...

[dcale]

For me it's the same issue, it doesn't matter what params I add I always get that answer.

[KirilKovachev]

Are you using standart https port(443)? There is pretty much the same problem in this thread: http://shibboleth.1660669.n2.nabble.com/Shibboleth-SP-2-3-1-FastCGI-Mode-Roxen-td4683380.html ?

[KirilKovachev]

If you are using port different than 443/8443 you should change shibboleth-sp source and recompile, as server scheme is set based on the port used: In shibboleth-2.6.0-src/fastcgi/shibauthorizer.cpp: const char server_scheme_str = scheme; if (!server_scheme_str || !server_scheme_str) server_scheme_str = (m_port == 443 || m_port == 8443) ? "https" : "http"; m_scheme = server_scheme_str;

In shibboleth-2.6.0-src/fastcgi/shibresponder.cpp: const char server_scheme_str = scheme; if (!server_scheme_str || !server_scheme_str) server_scheme_str = (m_port == 443 || m_port == 8443) ? "https" : "http"; m_scheme = server_scheme_str;

[dcale]

@KirilKovachev fantastic, this was it... I am running behind a proxy/loadbalancer that handles all the SSL traffic, faking/passing the PORT via variables did not work. But doing as you suggested (setting nginx to port 443) worked now! Also it does not matter if that nginx is really dealing with SSL or not, it's really only the port.

My Setup loadbalancer (443 & SSL) -> docker nginx (443 & plain HTTP) -> fastcgi

[davidjb]

FYI I've got an untested patch to read the FastCGI param REQUEST_SCHEME to avoid needing to recompile the FastCGI apps from scratch at https://github.com/nginx-shib/cpp-sp/commit/c63f1ca437cb2090cc5e5fb6c8bd961c0345bb51 for this issue. If you want to test that and let me know, I can get the patch added into Shib's core.

[kazooo]

@davidjb Hello, thank you for your work, I have a configuration

http {

    ...

    server {
        listen 81;
        listen [::]:81;

        root /home/client;
        index index.html;

        location ~ ^/api/(.*)$ {     # works fine
            resolver 127.0.0.11;
            proxy_pass http://backend:8080/search/$1$is_args$args;
        }

    location / {
            try_files $uri $uri/ /index.html;
        }
    }

    server {
        listen 80;
        listen [::]:80;

        server_name host_name.com;

        location / {
            proxy_pass http://localhost:81/;
        }

    #FastCGI responder
        location /Shibboleth.sso {     # need it in server:80
            include fastcgi_params;
            fastcgi_param REQUEST_SCHEME https;
            fastcgi_param SERVER_PORT    443;
            fastcgi_pass unix:/opt/shibboleth/shibresponder.sock;
        }        
    }

    server {
    listen 443;
        listen [::]:443;

    #FastCGI authorizer for Auth Request module
        location = /shibauthorizer {
            internal;
            include fastcgi_params;
            fastcgi_param REQUEST_SCHEME https;
            fastcgi_param SERVER_PORT    443;
            fastcgi_pass unix:/opt/shibboleth/shibauthorizer.sock;
        }

    #Resources for the Shibboleth error pages. This can be customised.
        location /shibboleth-sp {
            alias /usr/share/shibboleth/;
        }

    #A secured location.  Here all incoming requests query the
        #FastCGI authorizer.  Watch out for performance issues and spoofing.
        location /secure {
            include shib_clear_headers;
            shib_request /shibauthorizer;
            shib_request_use_headers on;
            proxy_pass https://$host/Shibboleth.sso/Login?target=https%3A%2F%$host%2FShibboleth.sso%2FSession;
        }
    }
}

Unfortunately when I try to login, it sends "return" parameter to Discovery service with value

[return] = [http://host_name.com/Shibboleth.sso/Login?SAMLDS=1&target=...]

that doesn't match value used in metadata of service (must be https://host_name.com...). When I manually change "return" value in URL, it normally passes me to authorization page, but after authorization it fails on

shibsp::ConfigurationException
The system encountered an error at Fri Aug 28 xx:xx:xx 2020
To report this problem, please contact the site administrator at root@localhost.
Please include the following message in any email:
shibsp::ConfigurationException at (http://host_name.com/Shibboleth.sso/SAML2/POST)
Shibboleth handler invoked at an unconfigured location.

and here I see "http://" again... I thought that REQUEST_SCHEME overriding should solve the problem, but it doesn't. I tried change server_name in server:80 to

server_name https://host_name.com;

but it immediately fails on "FastCGI Shibboleth responder should only be used for Shibboleth protocol requests." All handlerSSL are "false".

Can you see any mistakes here in my config? Maybe you can guess where I made a mistake. Thank you!

[davidjb]

@kazooo Unfortunately, this is a bug tracker and not a support forum. For setup of this module, see https://github.com/nginx-shib/nginx-http-shibboleth/blob/master/CONFIG.rst - your config looks messy and you should serve your application via HTTPS (it's required for my Shibboleth federation); check your shib SP configuration as per the CONFIG doc above. Beyond that, you can try posing your question to the Shibboleth mailing lists.

[smoebody]

FYI I've got an untested patch to read the FastCGI param REQUEST_SCHEME to avoid needing to recompile the FastCGI apps from scratch at nginx-shib/cpp-sp@c63f1ca for this issue. If you want to test that and let me know, I can get the patch added into Shib's core.

@davidjb Since i just encountered this circumstance i was wondering whether your patch made it into the fastcgi-code. I find the issue-closing workaround hardly a perfect solution and would prefer your suggestion with REQUEST_SCHEME.

Thanks for the hard work.

Cheers

[davidjb]

@smoebody The patch wasn't ever incorporated into the core codebase but the patch appears to still apply cleanly. I haven't experienced this specific issue so I was leaving testing of the patch up to others that were.

I don't have the bandwidth to follow this up but you're welcome to take my patch (consider it licensed under Apache 2.0, as the rest of cpp-sp is) and follow up with the Shibboleth project. The issue tracker for this part of their project is https://shibboleth.atlassian.net/jira/software/c/projects/SSPCPP/issues/.

All the best with it - feel free to ping back here with the result.