This will be the last feature requirement I plan to check with the router service of WCF 4.
One of the core purposes for developing the router facade here at my workplace was to have our own layer where we could implement and ensure any kinds of standards/policies.
Few examples include encryption, SLA, authorization, logging, notifications. The list goes on.
These things require me to have control over the request and reply messages as well as the invocation process flow.
Let’s take a simple authorization for example -
Let’s assume we have a simplified authorization module we would like to implement in our router facade.
The router will determine if the client’s identity can call the desired operation (according to the message action) against some IDM and Permissions management layer. If the client is authorized, the router should flow the message to the back-end service. Otherwise, it should return an “access denied” security fault message to the client and never invoke the back-end service.
First thing first, intercepting the request message can be done using a message inspector.
Though what then?
If I validate the request and find that it is unauthorized, how can I cancel the invocation process and return a fault?
This is problematic in the current design of the routing service, which is the fifth point of failure.
Throwing a security exception during the “AfterReceiveRequest” in the authorization inspector doesn’t map to the appropriate access-denied fault when returned to the client. (it is discovered as a general Fault Exception)
Moreover, when dealing with duplex contracts, it is resolved as a different kind of exception (CommunicationException rather than FaultException)
The different behavior is due to the fact that duplex channels behave differently.
Exceptions should be created as fault messages and as any other message, needs to be sent over to the client through the duplex channel. This is why simple exception throwing doesn’t yield the same result, it raises a communication exception in this case.
Oddly enough, I did find that if you throw a SecurityException from a custom filter table that you implement it does map to the appropriate access-denied security fault back to the client, not sure it would work with duplex contracts though, haven’t tried that.
Concluding failure points so far:
- WebHttp isn’t supported as much as I could tell
- I didn’t succeed with calling a O/W operation on a back-end service exposed with WsHttpBinding and Reliable Session enabled
- I didn’t find a way to control the contract of the channel shape used by the router service down the chain when calling to the back-end service. That prevented me from controlling the invocation pattern if I have more information regarding the target back-end service and operation.
- I didn’t find a way to get a hold of the reply messages in duplex communication mode in order to apply my custom logic such as logging the messages passed through it in runtime.
- The router service is difficult to extend, having control over its invocation process is extremely limited, making it impossible to utilize it as a PEP.