How is the current ServiceSecurityContext determined?
If you access the ServiceSecurityContext through its static Current member, there are four things that need to be true to get a valid ServiceSecurityContext.
- You need to have an ambient OperationContext
- The OperationContext needs to have a valid Message instance related to the operation underway
- The Message instance must not have disposed its MessageProperties collection
- The MessageProperties collection must contain the MessageSecurityProperty that was computed
Some of these are not going to be available early on during message processing, such as the OperationContext, and some of these are going to start disappearing as you follow along cleanup and recovery paths, such as the Message instance during error handling.
Once things start disappearing, you’re out of luck unless you’ve gone to the trouble of preserving a copy of the information you need. For example, you might save the Message instance or particular message properties prior to entering error handling so that you have access to that information later on.
On the reverse side, when things are still early on, you generally do have access to the Message instance and the included MessageSecurityProperty, so you can fish things out manually as needed. However, depending on where you are during processing, you may be grabbing information prematurely and see the security context before the actual context that the service will be provided is available.