Throwing Exceptions from Service Authorization Manager

When writing your own service authorization manager, you override the CheckAccess or CheckAccessCore methods to put in your logic for granting access. CheckAccess returns a boolean, which means that the options for expressing yourself are limited. If the result is true, then access is granted. If the result is false, then access is denied.

However, you can actually be much more expressive if you'd like.

If you trace through the authorization process a bit, then you'll see that returning false simply translates into the infrastructure throwing an exception. That exception is a FaultException that represents a sender fault for failing to properly authenticate. A little bit of thinking shows that rather than returning true or false, you could instead throw your own fault exception. It turns out that your fault exception does get propagated through, just like the system one, and a FaultException lets you be a lot more verbose than a boolean.

Other types of exceptions will also get through although I don't recommend getting too adventurous. Being expressive is an advantage for the sender but a liability for the receiver. The receiver actually has to handle what you throw at it and try to do something intelligent with it. As you become more creative as a sender, receivers become less likely to actually do what you want them to.

Next time: Reading Messages for Validation

Comments

• Anonymous
  January 22, 2008
  How do I configure the validation process for certificates specified in the service credentials section?

• Anonymous
  January 27, 2008
  3 states in travel last week, 3 more this week. I'm now Silver on US Despair and headed up on Southwest