Export env var (e.g. MAG_ERR) with the kind of error precluding authentication

[alejandro-perez]

Related to #128

The gss_authenticate_user() an return error 401 for several causes. Mainly:

• Client hasn't sent any authentication data, giving up
• Unsupported authentication type (%s) requested by client
• Failed to create internal context: probably not enough memory
• GSS mech specific failure

My proposal is to export a variable (MAG_ERROR??) that indicates this cause with some textual constant (e.g. NO_AUTH_DATA, UNSUP_AUTH_TYPE, INTERNAL_ERR, GSS_ERR), to allow web developers to show a little more information to the user about the cause of the error.

[simo5]

What's the use case here ?
it is not easy to propagate errors in env vars in this case, but I guess we could try if there is a good reason to expose this.

[simo5]

Btw, what is gss_authenticate_user() ?

[alejandro-perez]

First, sorry about mentioning gss_authenticate_user(). I'm working on the Moonshot's Negotiate module (you might remember it from #62, http://www.project-moonshot.org/git/mod_auth_kerb.git) and, although several similarities on the base code, they are different on many things. In fact, the Moonshot's module is based on mod_auth_kerb, that's why I talked about the gss_authenticate_user() function that you don't have.

Nonetheless, the use case persist. Moonshot performs a GSS-EAP authentication: a multi-roundtrip federated mechanism that makes use of EAP and RADIUS to perform the authentication. The module can fail due to several circumstances (as noted in the initial comment), but you can subdivide them into two groupos:

1. The authentication is not performed due to some misconfiguration (e.g. user does not have Moonshot installed, or has not configured any credential, etc.). In this cases, the Negotiate exchange is never performed.
2. The authentication process is started, but the GSS loop fails at some point (e.g. the user introduced invalid credentials, the RADIUS server is down, etc.).

In my use case, I need (would like) to give the end user a little more information about the reason of the failure than just a HTTP 401 failure page. If the failure is due to a misconfiguration, I would like to tell them so (e.g. "The authentication was not performed at all, please check that you have installed the required SW, etc."). If the GSS authentication is performed, but fails, I'd like to tell them why (that why I also created #128).

I want to stress that these issues I created just want to bring your attention to something I thought might be useful while developing the other (similar) module, but in no way pretend to force you in any particular direction. Please, consider them as feedback. The imperative nature of the title is just because that's how typical issues are written.