Project

General

Profile

Feature #2967

mod_authn_gssapi requires delegation?

Added by lameventanas about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
mod_auth
Target version:
Start date:
2019-07-17
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description

Currently mod_authn_gssapi requires delegation in order to authenticate the client.

It should be optional, this patch makes it so.

History

#1

Updated by gstrauss about 1 month ago

  • Category set to mod_auth

Thank you for your patch. I'll look at it more closely soon.

To maintain compatibility with current behavior, should there be a lighttpd configuration option added to disabling the requirement of cred delegation?

When delegating creds, why did you change failure to store the creds to simply a warning rather than an error?

Please wrap (at least) the outer if () with if () { ... } rather than multi-line if statements without curly-braces, and do not remove add spurious whitespace changes (removing line)

Please also validate that your patch is produced from the latest lighttpd development (HEAD of lighttpd git master) or that you specify the version of lighttpd source code from which you produced the patch.

#2

Updated by lameventanas about 1 month ago

Thanks for looking into this.

Yes, this patch is from the latest lighttpd development, but I guess I will have to make a new one once we agree on how to handle this.

I think whether credentials are delegated or not shouldn't influence the outcome of the ongoing authentication, and the current behavior is a bug.

Delegated credentials aren't used by lighttpd, but can be used by whatever CGI follows. Then, how about letting the CGI choose the course of action? (ie: continue with less functionality, deny access, show instructions on how to configure the browser).

We could add a config option to control if credentials are saved at all, and how to handle them, something like:

auth.backend.gssapi.store-credentials = yes|no[|forced]

Some possible ways of implementing this:

store-credentials Behavior Delegated Stored Outcome
A yes Patch v1 false Allow (CGI can follow up if needed)
true false Allow (CGI can follow up if needed)
B yes Apache's way false Allow (CGI can follow up if needed)
true false Server error 5xx
C yes Backward compatible-ish false Deny
true false Server error 5xx
D yes Patch v1 false Allow (CGI can follow up if needed)
true false Allow (CGI can follow up if needed)
forced Backward compatible-ish false Deny
true false Server error 5xx
E yes Apache's way false Allow (CGI can follow up if needed)
true false Server error 5xx
forced Backward compatible-ish false Deny
true false Server error 5xx

If we go this route, my preference in order is: A, B, D, E, C

#3

Updated by gstrauss about 1 month ago

  • Tracker changed from Bug to Feature

I think whether credentials are delegated or not shouldn't influence the outcome of the ongoing authentication, and the current behavior is a bug.

The current module behavior is the same as when it was released. The behavior is functional.

Your opinion ("I think") does not qualify what is and is not a bug. You are going to have to get over yourself if you would like this conversation to continue.

Let me be clear: you are making a feature request to loosen a requirement in the code. The way it was coded was not an accident and is not a bug. You are making a feature request that the code be modified to support an alternate use case. It is a reasonable feature request, which is why I am entertaining it, but it is not a bug.

#4

Updated by gstrauss about 1 month ago

Untested patch, but I think this what you are requesting. Is it?

--- a/src/mod_authn_gssapi.c
+++ b/src/mod_authn_gssapi.c
@@ -421,17 +421,16 @@ static handler_t mod_authn_gssapi_check_spnego(server *srv, connection *con, plu
         goto end;
     }

-    if (!(acc_flags & GSS_C_DELEG_FLAG)) {
-        log_error_write(srv, __FILE__, __LINE__, "ss", "Unable to delegate credentials for user:", token_out.value);
-        goto end;
-    }
-
     /* check the allow-rules */
     if (!http_auth_match_rules(require, token_out.value, NULL, NULL)) {
         goto end;
     }

-    ret = mod_authn_gssapi_store_gss_creds(srv, con, p, token_out.value, client_cred);
+    ret = 1; /* success */
+
+    if (acc_flags & GSS_C_DELEG_FLAG)
+        ret = mod_authn_gssapi_store_gss_creds(srv, con, p, token_out.value, client_cred);
+
     if (ret)
         http_auth_setenv(con, token_out.value, token_out.length, CONST_STR_LEN("GSSAPI"));

#5

Updated by lameventanas about 1 month ago

It looks good, the only difference is that it sends a 401 status when credentials can't be stored.

Here is another one, it adds a "auth.backend.gssapi.store-credentials" option (disabled by default).
It returns a 500 status if enabled and there is an error storing the credentials.
This is how the Apache module works.

Also available in: Atom