I am also running into an issue running the app-mem-basic-decorate test case within the TCK on WildFly I would like to discuss.
The implementation of the decorator I believe does not adhere to the requirements of the Jakarta Authentication specification, specifically regarding wrapping the HttpServletRequest:
The restrictions on a ServerAuthModule are described in section
3.9.3.5:
"During validateRequest processing, a ServerAuthModule must NOT unwrap a message in MessageInfo, and must NOT establish a wrapped message in MessageInfo unless the ServerAuthModule returns AuthStatus.SUCCESS"
Line 57 is really contrary to the second half of this sentence as it is being set to detect a failed authentication rather than as a result of deciding to send "AuthStatus.SUCCESS". This isn't actually causing me an issue but maybe worth reconsidering.
I see how that could come across as confusing, although technically (but see next comment) this is not what is happening here. 3.9.3.5 is about not "returning" a wrapped response when the status is not "AuthStatus.SUCCESS".
E.g. only after "AuthStatus.SUCCESS" is "the resource invoked" (the Servlet chain, including Filters called). I believe the idea of this restriction is that a wrapped response would be intended for the next Servlet and/or Filter, which in that case would not be called.
But as the wrapped response is not "returned" (only used internally during processing), in principal no rules would have been violated (but again see next comment):
Or in some pseudo code:
Messaging runtime:
Object responseMessage = ...
messageInfo.setResponseMessage(responseMessage);
Call validateRequest(messageInfo);
if (AuthStatus.SUCCESS) {
invokeResource(...)
} else {
if !responseMessage.equals(messageInfo.getResponseMessage()) {
throw new Exception("illegal wrapping");
}
}
That's why the following part is there:
} finally {
// Restore the original response
httpMessageContext.getMessageInfo().setResponseMessage(response);
}
The test only uses the getError for a quick detection of failure, and wouldn't care about a response being reset by itself. It was done so not to violate 3.9.3.5 in principal.
Line 77 however is causing me an issue as the ServerAuthModule "must NOT" unwrap the message in MessageInfo so within WildFly we are detecting this banned action and rejecting it. This in turn is leading to the TCK test failing.
So the confusion is with this definition:
"if a ServerAuthModule calls MessageInfo.setResponseMessage(), the response argument must be an HtppServletResponseWrapper that wraps the HttpServletResponse within MessageInfo, or the response argument must be an HttpServletResponse that is wrapped by the HttpServletResponseWrapper within MessageInfo"
In this very strict definition:
MessageInfo.setResponseMessage(HtppServletResponseWrapper) // counts as wrapping
MessageInfo.setResponseMessage(HttpServletResponse) // counts as unwrapping
By setting the original response again, it would by that definition count as unwrapping, even if there's no actual unwrapping of any kind being done.
So going back to this:
"During validateRequest processing, a ServerAuthModule must NOT unwrap a message in MessageInfo, and must NOT establish a wrapped message in MessageInfo unless the ServerAuthModule returns AuthStatus.SUCCESS"
That all seems to be fine. During processing no unwrapped message is set (instead, a wrapped one is), and after processing there is no wrapped message present (instead, the original one is, which could say is unwrapped).
Now if you look at this one, it's perhaps confusing:
"if a ServerAuthModule calls MessageInfo.setResponseMessage(), the response argument must be an HtppServletResponseWrapper that wraps the HttpServletResponse within MessageInfo, or the response argument must be an HttpServletResponse that is wrapped by the HttpServletResponseWrapper within MessageInfo"
It's stated that way such that one can not set an arbitrary response. It must always be the response by either adding a wrapper layer, or removing one, of the version that is currently set in message info.
So if you look at what the test does
ResponseWrapper responseWrapper = new ResponseWrapper(response);
httpMessageContext.getMessageInfo().setResponseMessage(responseWrapper);
1. Wrapping during validateRequest - allowed
2. Argument is HtppServletResponseWrapper wrapping the HttpServletResponse currently in message info - allowed
httpMessageContext.getMessageInfo().setResponseMessage(response);
1. Not establishing a wrapped response - allowed (required)
2. Argument is HttpServletResponse unwrapping the HtppServletResponseWrapper currently in message info - allowed
I had to read the sections a couple of times as well, but I think the test should be correct. The code to detect unwrapping / wrapping by the implementation is quite subtle.
Kind regards,
Arjan Tijms
_______________________________________________
es-dev mailing list
es-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/es-dev
