nginx-shib / nginx-http-shibboleth

Shibboleth auth request module for nginx
https://github.com/nginx-shib/nginx-http-shibboleth/wiki
Other
209 stars 27 forks source link

Question: shibboleth behind proxy #31

Closed vidiecan closed 6 years ago

vidiecan commented 6 years ago

Unless I miss the obvious, it should be possible to have a mini public machine with nginx as load balancer/proxy (let's call it vm-public-front) and have shibauthorizer and shibboleth software at a private VM proxied from vm-public-front. Shibboleth would secure locations (e.g., vm-private-services) that are proxied from vm-public-front.

Is this correct?

Thank you!

davidjb commented 6 years ago

If you're placing the Shibboleth SP software on vm-private-services there's two options, either:

  1. You'll need to run Nginx on vm-private-services as well to host the FastCGI applications, or
  2. Make shibauthorizer and shibresponder running on vm-private-services available over TCP sockets to Nginx on vm-public-front (rather than local UNIX domain sockets).

So your setup is either:

Public VM                                   -->    Private VM
(nginx)                                            (nginx + this nginx-http-shibboleth module + shib run using UNIX sockets)

or

Public VM                                   -->    Private VM 
(nginx + nginx-http-shibboleth module)             (shib run using TCP sockets)

Either way something needs to be hosting the FastCGI applications (see the Configuration examples). Current examples show Nginx/Shibboleth communicating via UNIX sockets on the same machine but there's no reason you couldn't use TCP with fastcgi_pass instead. If you are using TCP, then ensure your network traffic between the VMs is secure, perhaps over a tunnel or equivalent.

The other alternative is to run Shibboleth on vm-public-front and just your application(s) on vm-private-services; the Shibboleth SP can be configured for multiple hostnames, paths, applications etc if that was a concern.

vidiecan commented 6 years ago

Thank you for the answer!

We have been running everything on vm-public-front for years and it worked perfectly but the time is ripe for a change. We want to have the public vm as small as possible so we will go as expected.

vidiecan commented 6 years ago

@davidjb one more thing, would it work if I want the Shibboleth SP software including nginx and nginx-http-shibboleth module not on vm-private-services but on yet another dedicated machine e.g., vm-private-shibboleth?

davidjb commented 6 years ago

Yep, you could run the stack anywhere you want and split it any way your see fit. The only two pieces that must be together are Nginx and nginx-http-shibboleth (as they're the same process) and this instance of Nginx needs to be able to connect to your application, wherever and however that may be, to pass through the Shibboleth variables.

The recommendation is to use environment parameters (eg fastcgi_param, uwsgi_param or scgi_param directives) to pass the variables, which is more secure and avoids spoofing, and each of these upstreams can operate over sockets as well as TCP. If your backend application requires HTTP proxying (eg via proxy_pass), then you can use shib_request_use_headers on to pass the variables as headers, but be extremely careful because headers can easily be spoofed. There's an example of how to clear headers at https://github.com/nginx-shib/nginx-http-shibboleth#configuration. Definitely thoroughly test before putting the config into production.

cjbottaro commented 6 years ago

Make shibauthorizer and shibresponder running on vm-private-services available over TCP sockets to Nginx on

How to do this? Running either just exits immediately with:

# shibresponder
Shibboleth initialization complete. Starting request loop.
Request loop ended.

I'm running them in Docker containers, so there is no need for supervisord.

cjbottaro commented 6 years ago

Figure it out. Need to install spawn-fcgi then run

spawn-fcgi -p $PORT -n -- /path/to/shibresponder

That will keep it in the foreground and thus compatible with Docker.

I was born in the 80's, but even for me this kind of stuff (fcgi) is ancient.

davidjb commented 6 years ago

@cjbottaro So supervisord is just a way of running the FastCGI applications in the right way, as you've found you can do with spawn-fcgi. So it's more of a case of something has to run the FastCGI applications rather than supervisord not being needed at all.

cjbottaro commented 6 years ago

One last piece of the puzzle... I'm still confused about how shibauthorizer and shibresponder communicate with shibd. My shibd is using a Unix socket at /var/run/shibboleth/shibd.sock, but I can't figure out how to configure shibauthorizer and shibresponder to use that to talk to shibd.

If it helps, here's my "shibboleth-daemon" pod (running 3 containers, i.e. processes):

1) shibd listening on /var/run/shibboleth/shibd.sock
2) spawn-fcgi -p 3001 -n -- /path/to/shibauthorizer
3) spawn-fcgi -p 3002 -n -- /path/to/shibresponder

Then my Nginx config for my shibboleth-http pod (the relevant parts):

    location = /shibauthorizer {
      internal;
      include fastcgi_params;
      fastcgi_pass shibboleth-daemon:3001;
    }

    location /Shibboleth.sso {
      include fastcgi_params;
      fastcgi_pass shibboleth-daemon:3002;
    }

    location /users/shibboleth/init {
      shib_request /shibauthorizer;
      shib_request_use_headers on;
      proxy_pass http://ua-web;
    }
  }

Once I figure all this out, I promise I'll write a post about how to do an HA Shibboleth deployment with Kubernetes, including docker-compose files to build all the images. 👍

vidiecan commented 6 years ago

@cjbottaro On the internet facing proxy, we have

189   # FastCGI authorizer for Auth Request module
190   location = /shibauthorizer {
191     internal;
192     include fastcgi_params;
193     fastcgi_pass vm_shibbie_authz;
194   }
195
196   # FastCGI responder
197   location /Shibboleth.sso {
198     include fastcgi_params;
199     fastcgi_pass vm_shibbie_resp;
200   }
  6 upstream vm_shibbie_authz {
  7     server 10.10.51.3:12344;
  8 }
  9
 10 upstream vm_shibbie_resp {
 11     server 10.10.51.3:12345;
 12 }
 13

And on 10.10.51.3 we have in supervisord

  1 [program:shibboleth]                                                 
  2 command=/opt/shibboleth-sp/sbin/shibd -F -f                          
  3 stdout_logfile=/var/log/supervisor/shibd.log                         
  4 stderr_logfile=/var/log/supervisor/shibd.error.log                   
  5 autorestart=true                                                     
  6                                                                      
  7 [fcgi-program:shibauthorizer]                                        
  8 command=/opt/shibboleth-sp/lib/shibboleth/shibauthorizer             
  9 socket=tcp://0.0.0.0:12344                                           
 10 user=www-data                                                        
 11 stdout_logfile=/var/log/supervisor/shibauthorizer.log                
 12 stderr_logfile=/var/log/supervisor/shibauthorizer.error.log          
 13                                                                      
 14 [fcgi-program:shibresponder]                                         
 15 command=/opt/shibboleth-sp/lib/shibboleth/shibresponder              
 16 socket=tcp://0.0.0.0:12345                                           
 17 user=www-data                                                        
 18 stdout_logfile=/var/log/supervisor/shibresponder.log                 
 19 stderr_logfile=/var/log/supervisor/shibresponder.error.log           
davidjb commented 6 years ago

@cjbottaro See my comment over on #33