When calling the job engine from a privileged context (e.g.: from within KapuaSecurityUtils.doPrivileged context on the client side), a MalformedAccessTokenException is thrown within the KapuaTokenAuthenticationFilter. Currently the class RebuildSessionFilter (extending KapuaTokenAuthenticationFilter) relies on the onAccessDenied in order to analyze the request headers and rebuild the KapuaSession correctly (due to shiro’s implementation of AccessControlFilter:
However by that point the response has already been modified in a 401 by KapuaTokenAuthenticationFilter.isAccessAllowed:
@Override
protected boolean isAccessAllowed(ServletRequest request, ServletResponse response, Object mappedValue) {
[...]
try {
return executeLogin(request, response);
} catch (AuthenticationException ae) {
return onLoginFailure(null, ae, request, response);
}
[...]
}
protected boolean onLoginFailure(AuthenticationToken token, AuthenticationException e,
ServletRequest request, ServletResponse response) {
HttpServletResponse httpResponse = WebUtils.toHttp(response);
httpResponse.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
//now I set a dummy header to propagate the error message to the CORSResponseFilter Class, that eventually will send this error message if CORS filter passes
httpResponse.setHeader("exceptionMessagePropagatedToCORS", handleAuthException(e));
return false;
}
Because of this, any other filter in the chain would likely fail. This is the case, for example, if the CORSResponseFilter si declared AFTER the ShiroFilter in the chain - as it should be, considering the CORS filter needs the current scope to be defined in order to retrieve origin endpoints configured for that specific client.
It could be argued that CORS is not needed at all for the Job Engine, as this component is exposed only in the intranet, and therefore called only internally, however:
it’s still wrong to invoke a potentially expensive jwt parsing code, and throwing an exception just to ignore it afterwards (exception handling is, as always, very costly)
other filters might need to be added in the future, and could fail due to the dirty response
This PR moves the “trusted” header identification directly into the RebuildSessionFilter.isAccessAllowed method, overriding completely the underlying implementation if a trusted context is present.
When calling the job engine from a privileged context (e.g.: from within KapuaSecurityUtils.doPrivileged context on the client side), a MalformedAccessTokenException is thrown within the KapuaTokenAuthenticationFilter. Currently the class RebuildSessionFilter (extending KapuaTokenAuthenticationFilter) relies on the onAccessDenied in order to analyze the request headers and rebuild the KapuaSession correctly (due to shiro’s implementation of AccessControlFilter:
However by that point the response has already been modified in a 401 by KapuaTokenAuthenticationFilter.isAccessAllowed:
Because of this, any other filter in the chain would likely fail. This is the case, for example, if the CORSResponseFilter si declared AFTER the ShiroFilter in the chain - as it should be, considering the CORS filter needs the current scope to be defined in order to retrieve origin endpoints configured for that specific client.
It could be argued that CORS is not needed at all for the Job Engine, as this component is exposed only in the intranet, and therefore called only internally, however:
it’s still wrong to invoke a potentially expensive jwt parsing code, and throwing an exception just to ignore it afterwards (exception handling is, as always, very costly)
other filters might need to be added in the future, and could fail due to the dirty response
This PR moves the “trusted” header identification directly into the RebuildSessionFilter.isAccessAllowed method, overriding completely the underlying implementation if a trusted context is present.