Hello,
On 5/7/25 11:28, Gustaf Neumann (sslmail) wrote:
On 07.05.2025, at 09:45, Georg Lehner <jorge...@magma-soft.at> wrote:
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.
Well, there is always more, we can do!
Be aware, that there are already many authentication and access control modules
available. We have
- nsauthpam
- nsldap/nsldapd
- nsradiusd
- knspnego
- nsaccess
and inside OpenACS on top of that (xooauth), at least supporting
- azure (Microsoft Graph API)
- github
- site blocking via request monitor
together with the option to define multiple authorities in one system and
detailed access control.
Thanks for the list!
In our larger applications, we have the need in a single server to support at
the same time e.g. azure and local accounts (e.g., most schools require azure,
but not all users have azure accounts). All the OpenACS based authentication
uses a system based on signed cookies, which is usually significant better in
performance compared to going for every request to the backend.
I agree, backend authentication should only be used for getting session
credentials/cookies etc.
Is there already a session management module available for Naviserver?
The OpenACS based system uses preauth filters, where the workflow of a request
is
1) recieve request
2) preauth filter
3) auth call
4) postauth filter
5) request proc
6) trace
Note, that none of “our” sites uses nsperm. In the work towards NaviServer 5, i
have added more functionality to nsperm and integrated it in security sensitive
applications (nsstats, nscp) to provide a single source for authentication and
to avoid hard-coded passwords; it provides an infrastructure for basic needs
(e.g. user management), so it is useful for small applications (it won’t work
well with a few hundred thousand users, we have in our larger systems). nsperm
is just intended for users with plain NaviServer applications.
On the C-level, NaviServer provides in the possibility to register an authProc
via Ns_SetRequestAuthorizeProc(), which has to return NS_OK, NS_UNAUTHORIZED,
NS_FORBIDDEN, or NS_ERROR. Currently, only nsperm uses this, and the
infrastructure allows only a single proc to be registered there. I could
imagine making this more flexible by
- allowing a chain of responsibility (multiple authProcs),
- allowing to add a Tcl handler for this.
Yes: that sounds great!
But at the end, this is not much different to the list of PREAUTH filters, we
have now. OpenACS preauth filter does much more than just authentication (e.g.
setup for performance monitoring, sets up session variables, handles redirects
to canonical URLs, …), and it decides based on the sitemap and its permissions,
whether authentication is actually needed. So, all you are sketching below can
be done via a preauth filter.
At which moment is the authProc called? before or after the preauth filter?
Best Regards,
Georg
Probably, the main difference between the preauth filter and the potentially
added list of authenticators is that the auth call are performed always,
whereas the filter might care about it. And, secondly, that autcall is intended
for authentication, whereas it is not clear to a beginner, that the preauth
filter is supposed to do it. Furthermore, it can open the authorization system
of OpenACS to multiple authorities, even when nsperm is installed. So, using
the authProc is architecturally better. For OpenACS applications, i would not
expect any differences, the user benefits would be non-existing.
all the best
-gn
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
_______________________________________________
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
