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

How does this work?? #33

Closed cjbottaro closed 6 years ago

cjbottaro commented 6 years ago

Description of Question

  1. Does shibd need to be running for shibauthorizer to work?
  2. If not, where does shibauthorizer look for config files, like shibboleth2.xml and attribute-map.xml?
  3. What is shibresponder for?

Setup

{{- $values := index .Values .Values.region .Values.env }}

daemon off; # We're in a container.
pid /var/run/nginx.pid; # Why with daemon off? Something about how this nginx was built (not us).

user root; # Container, come on. And we need access to shib/authorizer.sock running (as root) in a sidecar container, and mounted into this container.

include modules/http_shibboleth.conf;

worker_processes 1;

events { worker_connections 1024; }

http {

  # F-ing container already.
  access_log      /dev/stdout;
  error_log       /dev/stderr debug;

  server {
    listen {{ $values.container_port }};
    server_name *.{{ $values.domain }};

    location /ping {
      add_header Content-Type text/plain;
      return 200 'pong';
    }

    #FastCGI authorizer for Auth Request module
    location = /shibauthorizer {
      internal;
      include fastcgi_params;
      fastcgi_pass unix:/var/run/shib/authorizer.sock;
    }

    #FastCGI responder
    location /Shibboleth.sso {
      include fastcgi_params;
      fastcgi_pass unix:/var/run/shib/responder.sock;
    }

    #A secured location.  Here all incoming requests query the
    #FastCGI authorizer.  Watch out for performance issues and spoofing.
    location /users/shibboleth/init {
      # include shib_clear_headers;
      # Add your attributes here. They get introduced as headers
      # by the FastCGI authorizer so we must prevent spoofing.
      # more_clear_input_headers 'displayName' 'mail' 'persistent-id';
      shib_request /shibauthorizer;
      shib_request_use_headers on;
      proxy_pass http://ua-web;
    }
  }
}

Thanks for the help.

davidjb commented 6 years ago

How the FastCGI applications are implemented is part of Shibboleth SP rather than this repo (eg we didn't write the FastCGI applications; we're just using them). That said, to answer your questions:

  1. Does shibd need to be running for shibauthorizer to work?

Yes. The Shibboleth project considers the shibd daemon to be an "implementation detail" of the Shibboleth Service Provider, so it must be running regardless of which interface (Apache, FastCGI etc) you're using. I get the impression that running as a daemon could have been something else like a file-system based approach or database etc but that's how it was done. shibd get accessed at some point when the SP object is used; eg when methods are called on the object returned by the getServiceProvider() function in the FastCGI applications (source code). As for exactly when and for what, I don't know -- but given how I've seen it running, I expect shibd loads/caches config on start, handles active sessions and attributes, key exchanges and so on. Suffice to say it needs to be running and connectible for both shibauthorizer and shibresponder -- and for your Docker environment, it would need to be the same shibd instance since login and sessions are stateful.

  1. If not, where does shibauthorizer look for config files, like shibboleth2.xml and attribute-map.xml?

See above; these files are loaded by shibd. When I restart my shib stack, I restart shibd and shibauthorizer/shibresponder in that order -- this is especially important when changing hosts, paths and other webserver-related configuration in shibboleth2.xml as the FastCGI applications don't load this information (directly).

  1. What is shibresponder for?

It provides the /Shibboleth.sso endpoint for requests. See https://github.com/nginx-shib/nginx-http-shibboleth/blob/master/CONFIG.rst and https://github.com/nginx-shib/nginx-http-shibboleth/blob/master/README.rst#configuration. Under Apache, the Shibboleth plugin adds this handler automatically, but with Nginx, we're required to manually wire location blocks up ourselves.


If you want to know more about how these FastCGI applications work to learn how to adapt them to your Docker environment, then it's best to ask on the Shibboleth community Mailing Lists where the developers can help explain. The source code for the FastCGI apps is pretty slim so fairly easy to see what handled in FastCGI; all the heavy lifting of processing request is done by the Service Provider.

cjbottaro commented 6 years ago

It's not immediately obvious how shibauthorizer and shibresponder communicate with shibd. Is it over TCP? Is it over a Unix socket? If so, how to specify host/port or file location? Neither one of those programs have help text.

Also, fwiw, the documentation here doesn't mention shibd at all (the daemon, it does make mention of shibd the user).

Thanks again.

davidjb commented 6 years ago

It's Unix sockets (eg /var/run/shibboleth/shibd.sock) by default on *nix and TCP sockets by default on Windows. Take a look at https://wiki.shibboleth.net/confluence/display/SP3/Listener to look at how to reconfigure this option -- the "remoting" layer being referred to is shibd. As for how the FastCGI apps know to connect to this socket, as best I know, they read that information from shibboleth2.xml on startup.

Ask on the Mailing Lists for more info -- they're the devs so will be best placed to answer your questions. If that doesn't pan out, the source code is pretty clean so grep'ing can help too.