All - I think we need to determine the best way forward for our trusted proxy support.
Today, we have the details of the various ?doAs= vs ?username= parameters in the identity assertion httpServletRequestWrapper. Some services are coming into the fold with new or just plain different query parameter names. At this point, I believe our only course of action is a custom dispatch class for these services. Given that this is a constant and requires no real dispatching logic - I feel that we should avoid the custom code. This means that the values of the identity assertion parameters need to be configurable for each service. I would say this is true of anything that doesn't require custom dispatch logic. If we can avoid custom dispatches then we should do what we can to do so. That said, I think that we have at least two types of dispatches: 1. Some flavor of the DefaultDispatch class with variations of parameter names, maybe additional parameters, headers, etc. Even HA related code may fall into this category of dispatch. Currently, any HA handling requires a custom dispatch. 2. Completely different dispatch code that may even require a different client from HttpClient. For #1 we should be able to cut down on the number of custom dispatches by making certain things configurable - hopefully through the service definition itself. * identity assertion parameter names - for secure and unsecured clusters * excluded headers - some services require all the original headers - others do not Parameter names can be done in a couple different ways. We can move all the logic for determining the names to use into dispatch. This has been on the radar for some time as something that seems better architecturally. There *may* be some assumption that it has occurred already between the identity assertion provider and the dispatch but I'm sure if there is that it can be dealt with. The other is to leave it the way it is and intercept the request in the DefaultDispatch - or HttpClientDispatch layers and apply some rewrite to the query string to replace doAs with the configured value. This feels a little hacky but would work fine. This feature would allow us to work on service definitions even while the components are still working on adding trusted proxy support and we not end up surprised with an incompatibility due to a name mismatch. Thoughts? --larry
