Hello,
Reflecting on this topic I realize, that a more generic framework would
be beneficial, where authorization (ns_register_filter preauth ...) can
be combined with modular authentication.
Nginx has modules: access (IP based), auth_basic (http basic
authentication), auth_jwt (JWT authentication), auth_request (see last
Email), and probably some more.
Apache has probably even a more elaborated authentication infrastructure
with authz, authn and the access control functionality.
The Naviserver nsperm module kind of mixes together parts of what basic
apache authn/authz/access control provides and restricts its use to some
special cases.
- a global user database, valid for all servers.
- Either a global passwd file or a per server configurable passwd file
path. The later probably leading to name clashes.
- http basic auth
- a single global file within the module directory which maps paths to
permissions
- Either: a per server fixed, unchangeable filename for IP based access
control which only works for static web sites - .htaccess in to be
restricted directories - or a single global access control via two files
in the module directory: hosts.allow/hosts.deny
- - -
What do you think about an approach with an authentication module
"auth", to be configured like:
ns_section ns/server/$server/module/auth {
ns_param map "<method> <url_pattern> <authenticator> ?args?"
...
}
Where <authenticator> is a proc from some C or Tcl module which is
registered as in "ns_register_filter preauth".
In order to "deny all", one would need a wildcard <method>.
An "access" <authenticator> to only allow get on localhost (in an IPv4
only environment) could look like:
ns_param map "GET /* access allow 127.0.0.1"
ns_param map "* /* access deny 0.0.0.0/0"
A "nsperm" like user authenticator coud look like
ns_param map "* /* basic allow group nsadmin"
ns_param map "* /foo/* basic allow user bar"
ns_param map "* /* basic deny all"
...
Best Regards
Georg
On 5/5/25 19:12, Georg Lehner wrote:
Hello,
Nginx has an "auth_request"[1] module, which allows to offload
authentication to an HTTP backend.
This is used e.g. with oauth2-proxy[2] to provide OAuth2/OpenID
Connect authentication to (reverse proxied) applications which do not
implement authentication by themself. See configuration examples with
Keycloak[3] or authentik[4]
I believe, Naviserver would benefit from a compliant implementation of
this "authentication protocol" (and I would put it immediately into
operation).
How difficult would it be to implement this? Would this go into the
nsperm module or be rather implemented as a separate module?
- - -
Of course, replacing oauth2-proxy directly in Naviserver would be even
more efficient. E.g. Apache has its own mod_auth_openidc for this. But
I guess that's much harder to implent, and auth_request could also be
used with other creatively invented backends.
Best Regards,
Georg
[1] https://nginx.org/en/docs/http/ngx_http_auth_request_module.html
[2] https://github.com/oauth2-proxy/oauth2-proxy
[3]
https://oauth2-proxy.github.io/oauth2-proxy/configuration/providers/keycloak_oidc
[4]
https://docs.goauthentik.io/docs/add-secure-apps/providers/proxy/server_nginx
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
