I have a WCF service with multiple operations exposed as a RESTful API. Most operations on the service do not require authentication/authorization, but one or two do. The authorization policy I need to use is outside of my control, and is expensive to run. Therefore, I’d like to avoid using it on those operations that do not require it.
It appears that authorization policies defined in configuration must apply to the entire service – there is no way to apply them to selective operations. This means I need to come up with another mechanism to selectively apply the authorization policy to specific operations.
Operation behaviors don’t help because the ServiceSecurityContext.AuthorizationPolicies collection is read-only.
Splitting my service into two contracts – authorized and unauthorized – is messy, and won’t help anyway. In order to configure separate behaviors, I will need separate services (not just separate contracts implemented by the one service), so that each has a distinct name for the purposes of configuration. Separate services implies separate .svc files to point to those services, so all my RESTful URLs will change unless I have some crazy URI rewriting scheme. That seems way more work than should be required to make this happen.
I’m starting to think the only reasonable way to do this would be to write my own authorization policy that wraps the expensive one, and only call it for select operations. Of course, I’d need some way of identifying those operations, but I’ll cross that bridge when I come to it.
How can I selectively apply an authorization policy to service operations? Is there an easier way?
Since no one has replied, I’m going to say there is no way to do this so I can mark as accepted. I ended up doing exactly what I said – writing a wrapper authorization policy that selectively calls the expensive authorization policy based on some configuration.