When using WCF, you may want to integrate your security model into your application using claim based security. At this point, you will come across ServiceAuthorizationManager, which is responsible for evaluating policy statements to determine if the user is authorized to perform the requested operation. There is an interface, IAuthorizationPolicy, which you can implement to add your own claims to be evaluated by your ServiceAuthorizationManager implementation... there is one problem with this approach: the documentation you will find will most likely tell you to override CheckAccess in ServiceAuthorizationManager. However, if you merely override CheckAccess as in most of the provided samples, you will never see the output of your IAuthorizationPolicy implementation. As it turns out, the default implementation of CheckAccess sets up your security context as expected, but overriding CheckAccess will prevent this setup code from happening. Instead, override CheckAccessCore and your Security Context will be set up properly (the default implementation of CheckAccess sets up the context and then calls CheckAccessCore), or call base.CheckAccess as the first line in your handler to ensure that the basic setup of the security context happens before your code executes. This will save you hours of frustration.
Why in the world Microsoft didn't just split this up into two distinct methods such as InitializeSecurityContext and CheckAccess is beyond me. Generally Microsoft does a great job of Framework design, but this case seems to be an exception.