title: Ninject InRequestScope bound object does not keep state defined during AuthenticationManager execution
body: <p>I am having a rather perplexing problem with scope and WIF.  I have a service class (SecurityService) that handles all application security.  It creates claims, sets up the ClaimsPrincipal, etc.  It's bound up with Ninject.</p>
  
  <p>Now WIF has the ClaimsAuthorizationManager and ClaimsAuthenticationManager classes, plus a way to use cached principals, when appropriate.  Each of these two classes use the SecurityService, and the principal is created and stored on that class.</p>
  
  <p>I set up the code so that when the principal is cached, the SecurityService can receive that cached version and use it as an instance variable.  The service is bound InRequestScope().  Because the WIF classes require a constructor without parameters, I use the Ninject DependencyResolver.Current.GetService&lt;>() method.</p>
  
  <p>The problem is that it appears to be either creating a second copy, or the RequestScope has not started when the WIF work is occurring.  The SecurityService does not have a principal with claims assigned to it when it is assigned to objects in the code.</p>
  
  <p>Here is an example of the authentication manager</p>
  
  <pre><code>public class MyClaimsAuthenticationManager : ClaimsAuthenticationManager
  {
      private readonly SecurityService _MySecurityService;
  
      public HeritageClaimsAuthenticationManager(SecurityService heritageSecurityService)
      {
          _MySecurityService = heritageSecurityService;
      }
  
      public MyClaimsAuthenticationManager()
          : this(System.Web.Mvc.DependencyResolver.Current.GetService(typeof(SecurityService)) as SecurityService)
      {
      }
  
      /// &lt;summary&gt;
      /// Provides the framework extension to transform an incoming principal into an application specific principal.
      /// &lt;/summary&gt;
      /// &lt;param name="resourceName"&gt;&lt;/param&gt;
      /// &lt;param name="incomingPrincipal"&gt;&lt;/param&gt;
      /// &lt;returns&gt;An Application specific ClaimsPrincipal&lt;/returns&gt;
      public override ClaimsPrincipal Authenticate(string resourceName, ClaimsPrincipal incomingPrincipal)
      {
          if (incomingPrincipal != null &amp;&amp; incomingPrincipal.Identity.IsAuthenticated)
          {
              return TransformPrincipal(incomingPrincipal);
          }
          //Something is wrong with the incoming principal. Let the base implementation handle it.
          return base.Authenticate(resourceName, incomingPrincipal);
      }
  
      /// &lt;summary&gt;
      /// Given an existing claims principal, transform it to fit the needs of the current application,
      /// then store it in session.
      /// &lt;/summary&gt;
      /// &lt;param name="incomingPrincipal"&gt;&lt;/param&gt;
      /// &lt;returns&gt;&lt;/returns&gt;
      public ClaimsPrincipal TransformPrincipal(ClaimsPrincipal incomingPrincipal)
      {
          _MySecurityService.CreateHeritagePrincipal(incomingPrincipal);
          ...
          return _MySecurityService.Principal;
      }
  }
  </code></pre>
  
  <p>It uses the DependencyResolver due to the constructor requirements of WIF.  At this point, <code>_MySecurityService.Principal</code>  has value.  However, later in the request life cycle, Ninject returns a service that has no Principal.</p>
  
  <p>I also use an IHttpModule to intercept the WindowsPrincipal and use the authentication manager to transform the claims per <a href="http://leastprivilege.com/2012/04/04/identity-in-net-4-5part-2-claims-transformation-in-asp-net-beta-1/" rel="nofollow">http://leastprivilege.com/2012/04/04/identity-in-net-4-5part-2-claims-transformation-in-asp-net-beta-1/</a>.</p>
  
  <p>That also appears to work just fine.  When I change the binding from InRequestScope() to InSingletonScope(), everything works well.  Of course, this won't work with more than one user.  Also, when I look at the HttpContext.User, it has my ClaimsPrincipal.</p>
  
  <p>Here is the binding:</p>
  
  <pre><code>Bind&lt;ISecurityService&gt;()
      .ToMethod&lt;MySecurityService&gt;(
          m =&gt; new MySecurityService(
                   new Collection&lt;ISecurityClaimProvider&gt;()
                       {
                           new UserClaimDao(new MyDbContext("MyDbContext"))
                       }
                   )).InRequestScope();
  </code></pre>
  
  <p>Where the DAO is bringing back the application claims for the service, which happens above in <code>_MySecurityService.CreateHeritagePrincipal(incomingPrincipal)</code></p>
  
  <p>In summary, everything appears to be wired correctly.  It appears that Ninject operations in the WIF classes are happening outside request scope.</p>
  
  <p>Am I missing something?  Am I correct about the scope?  If so, is there a way round it?  If not, how are you dealing with this scenario?  </p>
  
  <p>Actually, I checked that Application_BeginRequest does occur before the WIF classes take action, so I'm at a complete loss.</p>