WIP Topic/support nginx auth request #43
Conversation
New optional endpoints: - sso-auth-addr: usable as target for auth_request queries by nginx, checks the 'sso' cookie for login-state - sso-login-addr: provides a simplistic login form, sets the 'sso' cookie Badly hacked components: - all endpoints get the session-store injected (reusing the pre-existing session store for this, although it's not really suitable because sessions are transient to the server lifetime, and expiration is hardcoded, it works for a prototype) - example nginx config, to be used within a server block - regular whawty-auth admin page login-form is badly hacked to support different base-paths
|
Also, I just saw that with a bit of JS you can make nginx use an oauth2 server as auth_request endpoint. With some hackery this means a single oauth2 endpoint used for So, solving issue #10 would be better. |
|
Yey but this needs the nginx javascript module which is not built by default and is not included in debian packages. Probably the js code can be rewritten using lua? |
|
Definitely: It's only there for parsing the JSON request, as OAuth2 always responds with 200 and embeds the auth-result, whereas with auth_request we need 200 vs. 401 vs. 403. |
|
actually what about this: https://github.com/sto/ngx_http_auth_pam_module |
|
Basically, yeah, why not. But then: Please tell me that this is not undefined behavior: https://github.com/sto/ngx_http_auth_pam_module/blob/d9286fc7b52e1a3584da2cb20423f912ec99169f/ngx_http_auth_pam_module.c#L234 ctx is proved false at this line, but I don't understand what's going on there. What I actually tried to find: because all browser vendors refused to make HTTP-integrated authorization properly usable (e.g. have a log-out button), I want to integrate a form-based login, not basic auth. Documentation is bare-bones, or I'm blind, but it seems like this uses HTTP auth only. BTW, auth-endpoint behind a proxy can make use of authentication caching rather easily. With a low-enough setting, this would still re-authenticate against whawty at every human initiated request, but signifcantly reduce the load against the backend without us having to do any caching; given that web apps love to make 100s of request for just about everything, this seems nice. |
|
Yeah you are right. So let's implement Oauth2 then. |
|
@gimpf fyi: I have a new need for something similar to what you proposed here. But in this case i also need to support authenticating against LDAP. Since i was not satisfied with the way Luzifer/nginx-sso handles things i created whawty/nginx-sso. You might want to take a look. |
|
Now that whawty.nginx-sso is released i will closed this PR. |
by far not ready yet
PoC technically works (tested w/radicale on nginx), but there's a lot of work still to be done:
sso-authendpoint needs support for sso-session via basic-auth or http-header (Android calendars don't do form login dance) ...?redir=argument must support whitelists (we do not want to leak successful login to potentially any adversary)Not strictly necessary, but I think useful in practice and as a showcase: whawty-auth admin page should be able to use the sso-login/auth mechanism.
Other stuff is more optional and can be added later:
and likely other stuff