title: Security, Thread.CurrentPrincipal, and ConfigureAwait(false)
body: <p>Would using Thread.CurrentPrincipal's claims in a referenced library that uses ConfigureAwait(false) pose any problems or will the flowing of ExecutionContext's logical call context take care of me there? (my reading and testing so far indicates that it will).</p>
  
  <p>Example WebAPI Controller Action:</p>
  
  <pre class="lang-cs prettyprint-override"><code>[CustomAuthorizeThatSetsCurrentUsersClaimsToThreadCurrentContextAndHttpContextCurrentUser]
  public async Task&lt;Order&gt; Get(int orderId)
  {
      return await _orderBusinessLogicLibrary.LoadAsync(orderId); // defaults to .ConfigureAwait(true)
  }
  </code></pre>
  
  <p>Example load functions from external, referenced library:</p>
  
  <pre class="lang-cs prettyprint-override"><code>[ClaimsPrincipalPermission(
      SecurityAction.Demand,
      Operation="Read",
      Resource="Orders")]
  [ClaimsPrincipalPermission(
      SecurityAction.Demand,
      Operation="Read",
      Resource="OrderItems")]
  public async Task&lt;Order&gt; Load(int orderId)
  {
      var order = await _repository.LoadOrderAsync(orderId).ConfigureAwait(false);
  
      // here's the key line.. assuming this lower-level function is also imposing
      // security constraints in the same way this method does, would
      // Thread.CurrentPrincipal still be correct inside the function below?
      order.Items = await _repository.LoadOrderItemsAsync(orderId).ConfigureAwait(false);
      return order;
  }
  </code></pre>
  
  <p>Also, the answer can't be "well don't use ConfigureAwait(false) then!".  That can cause other problems such as deadlock (<a href="http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html" rel="noreferrer" title="Don't Block on Async Code">Don't Block on Async Code</a>).</p>