Enforcing authentication requests for all resources under specific path

14 views
Skip to first unread message

Jan Wrobel

unread,
Mar 29, 2012, 10:32:32 AM3/29/12
to ng...@nginx.org, mdo...@mdounin.ru
Hi,

I'm working on an application independent authentication and
authorization layer that utilizes nginx with auth request module. The
two are working great for me, but I run into an issue that I don't
know how to solve, maybe you can help?

Is there a way to enforce auth requests for all resources under a
specific path? Say I want to protect all resources in /protected:

location /protected/ {
auth_request /auth/is_authenticated/;
error_page 403 /auth/login/;
error_page 401 /auth/noauthorized/;
}

This works but only until more specific location is added:

location /protected/blog {
#....
}

Which, due to location matching rules, takes precedence over the
'/protected' location, and auth requests for blog are not issued.

Is there any way around it other than repeating auth_request
configuration for each location?

I can think of two solutions, but each has quite substantial limitations:
1. configure auth_request in server {} section, but this authorizes
all requests, not only ones in '/protected'
2. Run separate nginx instance configured to do authorization only and
passing all allowed requests downstream. This would introduce
additional performance and maintenance overhead.

Is there any better way?

thanks,
Jan

_______________________________________________
nginx mailing list
ng...@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Igor Sysoev

unread,
Mar 29, 2012, 10:44:30 AM3/29/12
to ng...@nginx.org, mdo...@mdounin.ru

I believe the best way to configure is to set explicitly necessery
directives in all locations where they are required. This leads to
maintainable configuration.


--
Igor Sysoev

Jan Wrobel

unread,
Mar 29, 2012, 1:21:05 PM3/29/12
to ng...@nginx.org, mdo...@mdounin.ru

In my case this is not too good option. I need authentication layer
configuration to be independent from applications configuration. In
case of authentication (not only auth request but also auth basic)
repeating configuration for each location, without 'catch them all'
rule could lead to holes that are hard to notice. For example if I
configure authentication correctly for blog/*html but forget to do it
for blog/*.png the mistake will likely be unnoticed :/

Anyway, if there are no other options, I'll try using auth_request in
server{} section.

Thanks,
Jan

Francis Daly

unread,
Mar 29, 2012, 4:29:39 PM3/29/12
to ng...@nginx.org
On Thu, Mar 29, 2012 at 07:21:05PM +0200, Jan Wrobel wrote:

Hi there,

> In my case this is not too good option. I need authentication layer
> configuration to be independent from applications configuration. In

Because of the way nginx configuration works, they can't be completely
independent.

But you could try nesting locations:

location /protected/ {
auth_request etc...

location /protected/blog {
blog config...
}

location ~ png {
png config...
}

}

(And of course you'll want no top-level regex locations; but that's good
practice anyway.)

Quick testing suggests that the auth request module does inherit these
configurations.

f
--
Francis Daly fra...@daoine.org

Jan Wrobel

unread,
Mar 29, 2012, 4:53:22 PM3/29/12
to ng...@nginx.org
On Thu, Mar 29, 2012 at 10:29 PM, Francis Daly <fra...@daoine.org> wrote:
> On Thu, Mar 29, 2012 at 07:21:05PM +0200, Jan Wrobel wrote:
>
> Hi there,
>
>> In my case this is not too good option. I need authentication layer
>> configuration to be independent from applications configuration. In
>
> Because of the way nginx configuration works, they can't be completely
> independent.
>
> But you could try nesting locations:
>
> location /protected/ {
>  auth_request etc...
>
>  location /protected/blog {
>    blog config...
>  }
>
>  location ~ png {
>    png config...
>  }
>
> }
>
> (And of course you'll want no top-level regex locations; but that's good
> practice anyway.)
>
> Quick testing suggests that the auth request module does inherit these
> configurations.

Thanks, this works!

Jan

Reply all
Reply to author
Forward
0 new messages