Difference from ngx_http_auth_request_module

[zmousm]

Can you explain what the difference is from ngx_http_auth_request_module, presently? I've read the forum thread noted in README, but I am still not sure I understand correctly. Is it that this module will automatically set request headers from shibauthorizer response headers, while ngx_http_auth_request_module insists in suggesting the use of auth_request_set and, say, proxy_set_header? Is it something else?

Also, do you see any problem in building both this module and ngx_http_auth_request_module into nginx?

Thanks

[davidjb]

Hi @zmousm, there's two key differences:

1. The shib_request directive returns sub-request response statuses and headers from the to the client, whereas the original auth_request module only functions as a way to allow or deny access via 2xx or 401/403 respectively and considers any other response an error. This is mandatory in the Shibboleth authentication workflow (aka FastCGI authorizer) as redirections (eg 301s) must be passed back to the user so they can be redirected to WAYF pages, the Shibboleth responder (Shibboleth.sso) and so forth.
2. This module automatically extracts headers beginning with Variable-* from the subrequest response, stripping the Variable- portion of any such header names, and copies the headers into the main request. So, if the auth response returned a header like Variable-CN: John Smith, this module will add the header CN: John Smith into the main request for use by your application (eg the target of a proxy_pass or similar). By comparison, the ngx_http_auth_request_module doesn't do any automatic handling of headers; you could achieve a similar result with using auth_request_set but this is a lot of manual work, especially in Shibboleth environments with arbitrary user attributes.

There should be no issues with including both this module and ngx_http_auth_request_module in the same build. Using both modules in the same location block is untested; but it's unlikely this would be what you'd like to do.

Does that help answer your questions?

[zmousm]

Yes it does, great explanation, thank you very much!

This additional functionality (pass-through of authorizer status codes, translation of Variable- prefixed response headers to request headers), despite being particularly useful with Shibboleth SP, could (in principle) be used with any other authorizer, right?

[davidjb]

Most definitely, yes. Whilst the name is shib_request, the core aim is to adapt the FastCGI authorizer protocol for use by amy backend application.

As per my reading of the spec ( http://www.fastcgi.com/drupal/node/6?q=node/22#S6.3), if we were to try and conform strictly it, we'd restrict ourselves to FastCGI backend applications only. By passing the Variable- data as headers instead, we can support any backend. This ends up being exactly like mod_shib for Apache, which passes user variables as headers.

The only other key deviation from the FastCGI spec is that on returning a non-200 authorizer response to the client, we can't pass the authorizer response body back, only status and headers. I'd like to improve this, but it is due to Nginx not supporting this for subrequests (at least currently). The result for Shibboleth is minor, as only the HTTP response code and headers are needed to function. So if you had a FastCGI authorizer that was say generating a fancy page, the response body won't get to the client and will be handled by Ngnix instead.

If you're able to adapt this addon for your use, great! If there is something that we could improve (docs, functionality etc) send a pull request or open an issue. On Wed, 17 Feb 2016 at 01:20, Zenon Mousmoulas notifications@github.com wrote:

Yes it does, great explanation, thank you very much!

This additional functionality (pass-through of authorizer status codes, translation of Variable- prefixed response headers to request headers), despite being particularly useful with Shibboleth SP, could (in principle) be used with any other authorizer, right?

— Reply to this email directly or view it on GitHub https://github.com/nginx-shib/nginx-http-shibboleth/issues/10#issuecomment-184726310 .

[zmousm]

Yes I fully understand the limitation regarding the authorizer response body.

I am primarily interested in shib integration of course, but I have also been thinking about other scenarios.

Thanks so much for the explanation, very helpful!

[davidjb]

I've updated the readme with all details from this issue; it definitely need a rewording. If you could take a look at https://github.com/nginx-shib/nginx-http-shibboleth/blob/master/README.rst, I'd appreciate the feedback!

[zmousm]

Yes the write-up under the section 'Behavior' is very helpful, a nice improvement indeed.

Re: the last paragraph in the second bullet ("The spec calls for Variable-* name-value pairs...") I think that mod_shib defaults to using variables rather than headers and actually it mostly warns against the use of headers, due to potential security issues, however I believe your reasoning for preferring headers in this module and the precautions that must be taken in that respect is perfectly clear.

Thanks for this!

[davidjb]

Thanks @zmousm, I've clarified it a little more again, especially around drawing comparisons between mod_shib and this module with headers vs environment variables. For note, it would be good if this module supported both options, I just haven't had situation where environment variables could be used.