 |
 |
We're working on improving Moonshot's error handling and debugability. Today, all you typically get at the client is authentication rejected, and at the server is access reject. We've had some discussion on-list in the last week of the errors we'd like to distinguish. I'd like to discuss our mechanisms for doing that. On the server, we return an error using gss_display_status. A few years ago Kerberos introduced the convention that the message you get back from gss_display_status can be dynamic. You pass in a major and minor code, but the resulting message, especially for minor codes is not constant. It may depend on the circumstances of the most recent error. There are facilities in mech_eap for manipulating this. We already do a reasonably good job of mapping libradsec errors into moonshot errors and recovering the libradsec error message. So, on the server, we can return a fairly dynamic error message. I'm proposing that we first look to see if an access-reject has an error-cause attribute. That was defined in the COA spec, but based on some of the registered values, its usage seems to be more common. The main value from Error-Cause I want to retrieve are values related to proxy failures, particularly including the proxy routing failure code. If Error-cause is not present, or perhaps possibly even if it is, we look for reply-message. If there's EAP, that won't be present, but if things have failed so hard that the EAP was not processed, we can get a reply-message. Between the client and acceptor we have a more limited interface. The ABFAB error token contains a major status and a minor status as an unsigned 32-bit integer limited to the values 0-255 (see section 5.3 and 7.6 of RFC 7055) We will not be able to communicate out reply-message, but we will be able to parse out error cause codes and turn these into meaningful GSS-EAP errors. Then, we propose to write and send patches to FreeRADIUS to update the trust router code and ABFAB policy. We propose to populate reply message with trust router errors where appropriate and to generate error-cause from the more interesting trust router errors. In particular we'll generate a proxy routing error when we fail to find a trust path. We also want to generate an error-cause when the IDP rejects for authorization reasons. Thoughts on this approach? Alan, is error-cause the right thing to be using here? Typically the TR code returns noop or notfound rather than reject directly when a mapping isn't found. Should we define another internal attribute and populate error-cause when we turn that into a reject in unlang, or should we populate error-cause from the TR code directly? --Sam