Passing regex server names to authorizer

[IceNV]

We have a setup where Nginx determines virtual hosts using regular expressions, which is allowed in the server_name directive. These regular expressions are automatically generated by our server install scripts.

_Note : In the following example, there is only one server name for the machine I ran the test on, but sometimes the regex looks like ^(<sn>server[0-9]+\.ourdomain\.com)$, because it is a semi catch-all server and the directive would otherwise exceed the servername directive length limit. It is also used to capture the resulting server name and pass it upstream to PHP fastCGI backends.

However, the module seems to pass the regex, and not the matched name, to the fastCGI shibauthorizer. Indeed in the native.log log, I have this:

DEBUG Shibboleth.FastCGI FastCGI shibauthorizer: mapped https://~^(<sn>server19\.ourdomain\.com)$/secured_page.php5 to default

Instead of the expected:

DEBUG Shibboleth.FastCGI FastCGI shibauthorizer: mapped https://server19.ourdomain.com/secured_page.php5 to default

This, of course, makes the authentication redirection fail, since the host is defined in shibboleth2.xml as the result, not the regex.

If I define the host as the regex in the RequestMpper block of shibboleth's XML conf file, such as this :

<Host name="~^(?&lt;sn&gt;server19\.ourdomain\.com)$" authType="shibboleth" (...) >

instead of the original:

<Host name="server19.ourdomain.com" authType="shibboleth" (...) >

Then the authentication works.

While a temporary fix could be to set the regex as a hostname, the problem is that the regex could match multiple server names, and all of these servers would not necessarily require shibboleth authentication, or, could implement different SPs, etc ; Moreover, this kind of defeats the purpose of using a regular expression altogether.

Versions : Nginx : 1.10.1 Shibboleth + fastCGI : 2.6.0 (using supervisor to run shibauthorizer and shibresponder over unix sockets)

Note : the server and file names have been edited for confidentiality.

[davidjb]

Thanks for the report. It's been a while since I've tried, but I could never get the shibauthorizer or shibresponder FastCGI applications to log anything (even with every log setting on DEBUG). Could you share your logging config and/or how you got the logging to succeed?

Could you also share your nginx config (server/location blocks; anonymised if need be) as well? I'll then take a look and see if I can replicate the issue.

[IceNV]

In this case, the client was in a hurry, so we found a workaround by disabling the regex for now on this particular server (the previous workaround I mentioned in the original post does not work; the metadata echoes the regex and not the URL in that cases, which is incorrect.). Nevertheless, I'll try and give you the requested info.

Regarding logging : I only enabled the default log level to DEBUG (in /usr/local/shibboleth)/etc/shibboleth/shibd.logger) if I remember correctly. The log where I found this line is /usr/local/shibboleth)/var/log/shibboleth-www/native.log However, I didn't use a package to build Shibboleth, so maybe it is configured differently ? Here are the command lines used to build Shibboleth-SP on this server : (root here is /usr/local/shibboleth, you can probably replace it with / not to have it nested inside) :

apt-get install gcc g++ make libssl1.0.0 libssl-dev libcurl3 libcurl3-dev libxerces-c3.1 libxerces-c-dev libboost-dev libfcgi-dev -y
cd /tmp
mkdir shibbuild
wget http://shibboleth.net/downloads/log4shib/latest/log4shib-1.0.9.tar.gz -P shibbuild
wget http://shibboleth.net/downloads/c++-opensaml/latest/xmltooling-1.6.0.tar.gz -P shibbuild
wget http://shibboleth.net/downloads/c++-opensaml/latest/opensaml-2.6.0.tar.gz -P shibbuild
wget http://shibboleth.net/downloads/service-provider/latest/shibboleth-sp-2.6.0.tar.gz -P shibbuild
wget http://mirror.switch.ch/mirror/apache/dist/santuario/c-library/xml-security-c-1.7.3.tar.gz -P shibbuild
tar -zxvf shibbuild/log4shib-1.0.9.tar.gz -C shibbuild
tar -zxvf shibbuild/xmltooling-1.6.0.tar.gz -C shibbuild
tar -zxvf shibbuild/opensaml-2.6.0.tar.gz -C shibbuild
tar -zxvf shibbuild/shibboleth-sp-2.6.0.tar.gz -C shibbuild
tar -zxvf shibbuild/xml-security-c-1.7.3.tar.gz -C shibbuild
mkdir /usr/local/shibboleth
cd shibbuild/log4shib-1.0.9/
./configure --prefix=/usr/local/shibboleth --disable-static --disable-doxygen
make
make install
cd /tmp/shibbuild/xml-security-c-1.7.3/
./configure --prefix=/usr/local/shibboleth
make
make install
cd /tmp/shibbuild/xmltooling-1.6.0/
./configure --prefix=/usr/local/shibboleth --with-log4shib=/usr/local/shibboleth --with-xmlsec=/usr/local/shibboleth -C
make
make install
cd /tmp/shibbuild/opensaml-2.6.0/
./configure --prefix=/usr/local/shibboleth --with-log4shib=/usr/local/shibboleth -C
make
make install
cd /tmp/shibbuild/shibboleth-sp-2.6.0/
./configure --prefix=/usr/local/shibboleth --with-log4shib=/usr/local/shibboleth --with-xmltooling=/usr/local/shibboleth --with-saml=/usr/local/shibboleth --with-fastcgi -C
make
make install
cd
cp /usr/local/shibboleth/etc/shibboleth/shibd-debian /etc/init.d/shibd
chmod +x /etc/init.d/shibd
update-rc.d shibd defaults
/etc/init.d/shibd start
apt-get install supervisor -y
cp /home/conf/supervisord.conf /etc/supervisor/supervisord.conf
/etc/init.d/supervisor stop
/etc/init.d/supervisor start

The supervisord.conf blocks are as follows :

[fcgi-program:shibauthorizer]
command=/usr/local/shibboleth/lib/shibboleth/shibauthorizer
socket=unix:///tmp/shibauthorizer.sock
socket_owner=root:root
socket_mode=0666
user=root
stdout_logfile=/var/log/supervisor/shibauthorizer.log
stderr_logfile=/var/log/supervisor/shibauthorizer.error.log

[fcgi-program:shibresponder]
command=/usr/local/shibboleth/lib/shibboleth/shibresponder
socket=unix:///tmp/shibresponder.sock
socket_owner=root:root
socket_mode=0666
user=root
stdout_logfile=/var/log/supervisor/shibresponder.log
stderr_logfile=/var/log/supervisor/shibresponder.error.log

(Yeah, I know, having them run as root is pretty bad, but that's not the scope of the current problem.)

nginx config : attached. (with server names edited and other virtual servers removed) _Note : The server is able to switch names in certain cases, hence the separate nginx_namesself file. ngx.zip

Also note that the server name passed to PHP through FastCGI by the $sn variable correctly reflects the regex match result, and not the pattern.

Thank you, I hope this helps you debugging the problem.

[davidjb]

The FastCGI authorizer and responder both load the hostname out of the SERVER_NAME FastCGI parameter (ref) and by default, nginx is configured like so (in your fastcgi_params):

fastcgi_param  SERVER_NAME        $server_name;

In this case, the $server_name variable is the literal regex so that's why Shibboleth is seeing it. You'd need to change your config to add an override for SERVER_NAME into your Shibboleth location blocks like so:

location = /shibauthorizer {
    internal;
    include fastcgi_params;
    fastcgi_param SERVER_NAME $sn;
    fastcgi_pass unix:/tmp/shibauthorizer.sock;
}

location /Shibboleth.sso {
    include fastcgi_params;
    fastcgi_param SERVER_NAME $sn;
    fastcgi_pass unix:/tmp/shibresponder.sock;
}

You'd actually already solved it for the PHP FastCGI endpoints later in your configuration (eg the wayf/ location), this same line just needed to go into these blocks too. You could also use $host as well and avoid the <sn> capture; that is probably simpler/faster if performance is crucial.

For note, the docs on $server_name are light on details:

$server_name
    name of the server which accepted a request

and thus ambiguous when using regex. nginx's source code for this $server_name tells the story: it's just accessing the server config and loading the raw string; it doesn't evaluate the regular expression.

[davidjb]

Also FYI I opened https://trac.nginx.org/nginx/ticket/1171 as a documentation update for nginx. Feel free to +1 that or suggest further improvements.

[davidjb]

FYI that linked issue was closed with wontfix. At any rate, we now know what'll happen in this situation and hopefully improve the Google-fu of the situation.