I’ve written an additional feature into the Auth Request module (from
ngx_http_auth_request_module: log) that allows a user
to
control the behaviour of the auth_request in such a way that it can act
as a
FastCGI authorizer. This patch that I have written allows the user to
specify the flag “authorizer=on” against a call to “auth_request” (eg
“auth_request /my-auth authorizer=on;”) and the auth request module will
behave as per the authorizer specification
(http://www.fastcgi.com/drupal/node/22#S6.3).
There is one (potentially significant) caveat for now is that
request/response bodies are not passed to the authorizer or back to the
client respectively - assistance on this would be greatly appreciated.
However, as it stands at present, the authorizer mode is able to
correctly
handle situations where only the headers are utilised – eg the
Shibboleth
SSO FastCGI authorizer which relies on redirection and cookies and never
a
response/request body. This satisfies at least what I need it for at
present and authentication works successfully.
I’d like to see about whether this can be included within the main
module
itself at ngx_http_auth_request_module: log, as I know
this
will be useful to more than just me. For example, see the various posts
and
questions surrounding this:
fastcgi authorizer nginx - Google Search .
The latest version of my module lives at:
https://bitbucket.org/davidjb/ngx_http_auth_request_module
and the one main diff is located at:
https://bitbucket.org/davidjb/ngx_http_auth_request_module/commits/3d865a718d3e34e4e353962ccc71c588a806db31/raw/
Comments are more than welcome.
Thanks,
David
Posted at Nginx Forum:
Hello!
On Mon, Apr 22, 2013 at 12:35:51AM -0400, davidjb wrote:
request/response bodies are not passed to the authorizer or back to the
questions surrounding this:
fastcgi authorizer nginx - Google Search .
The latest version of my module lives at:
https://bitbucket.org/davidjb/ngx_http_auth_request_module
and the one main diff is located at:
https://bitbucket.org/davidjb/ngx_http_auth_request_module/commits/3d865a718d3e34e4e353962ccc71c588a806db31/raw/
Comments are more than welcome.
For me it doesn’t looks like what you do actually matches FastCGI
Authorizer specification. Even if we ignore the fact that body
isn’t handled properly, and authorizer mode isn’t advertized to
FastCGI.
Most of the code in the patch seems to be dedicated to special
processing of Variable-* headers. But they don’t seem to do what
they are expected to do as per FastCGI spec - with your code the
“Variable-AUTH_METHOD” header returned by an authorizer will
result in “AUTH_METHOD” header being passed to the application,
i.e. it will be available in HTTP_AUTH_METHOD variable in
subsequent FastCGI requests - instead of AUTH_METHOD variable as
per FastCGI spec.
Please also note that it’s bad idea to try to modify input headers -
this is not something expected to be done by modules, and will
result in a segmentation fault if you’ll try to do it in a
subrequest.
–
Maxim D.
http://nginx.org/en/donation.html
Maxim D. Wrote:
i.e. it will be available in HTTP_AUTH_METHOD variable in
subsequent FastCGI requests - instead of AUTH_METHOD variable as
per FastCGI spec.
It’s still very much a work in progress (fwiw, I started using Nginx
last
week). On another read of the FastCGI specification, I do agree that
your
interpretation is right - I was interpreting part of the specification
without understanding the rest of the definitions. So, in that regard
it
could certainly be improved.
However, if strictly adhering to the FastCGI spec, this would thus force
the
backend application to be FastCGI as well – and this is why my code
does
what it does. The authorisation technology (Shibboleth) I’m working
with
needs to inject user-related variables into the request going to a
backend
application, and for ease of use/performance, I don’t want to have to
re-route via a FastCGI application.
So perhaps on balance, this functionality may well be better suited to
its
own add-on module.
Please also note that it’s bad idea to try to modify input headers -
this is not something expected to be done by modules, and will
result in a segmentation fault if you’ll try to do it in a
subrequest.
Okay, but what of a module like “Headers more” – which allows you to
manipulate any headers, incoming or outgoing. Should something like
this
not exist for Nginx or is it just considered ‘bad practice’? Either
way,
I’d be curious for both the code I’ve written, and also as I’m relying
on
the “Headers more” module to drop certain request headers.
As for the code I’ve written, the input headers are being modified after
the
subrequest has been completed, and this appears to succeed. So no seg
faults so far.
Posted at Nginx Forum:
Hello!
On Tue, Apr 23, 2013 at 07:23:26PM -0400, davidjb wrote:
“Variable-AUTH_METHOD” header returned by an authorizer will
However, if strictly adhering to the FastCGI spec, this would thus force the
backend application to be FastCGI as well – and this is why my code does
what it does. The authorisation technology (Shibboleth) I’m working with
needs to inject user-related variables into the request going to a backend
application, and for ease of use/performance, I don’t want to have to
re-route via a FastCGI application.
So perhaps on balance, this functionality may well be better suited to its
own add-on module.
Note that if you just need to pass some variables you know about -
it can be easily done with auth_request_set and fastcgi_param
directives.
Please also note that it’s bad idea to try to modify input headers -
this is not something expected to be done by modules, and will
result in a segmentation fault if you’ll try to do it in a
subrequest.
Okay, but what of a module like “Headers more” – which allows you to
manipulate any headers, incoming or outgoing. Should something like this
not exist for Nginx or is it just considered ‘bad practice’? Either way,
I’d be curious for both the code I’ve written, and also as I’m relying on
the “Headers more” module to drop certain request headers.
This is considered bad and unsupported by nginx core. You may
take a look at headers more module for a number of quirks it uses
for this to work.
Recommended aproach is to use variables and appropriate backend
protocol module directives (proxy_set_header, fastcgi_param, …)
to pass them to a backend. An example of similar functionality in
nginx core:
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#variables
–
Maxim D.
http://nginx.org/en/donation.html