ClaimsAuthenticationManager

Question

I have code similar to the snippet below (taken from http://www.leastprivilege.com/UseGenevaSessionManagementForYourOwnNeeds.aspx)

public class Transformer : ClaimsAuthenticationManager
{
    public override IClaimsPrincipal Authenticate(string endpointUri, IClaimsPrincipal incomingPrincipal)
    {
  var claimName = "customClaimType";
  // expensive operation
  var claimValue = [from expensive operation];
  
        incomingPrincipal.Identities[0].Claims.Add(new
          Claim(claimName, claimValue));

        return incomingPrincipal;
 
    }
}

And in the article (http://www.leastprivilege.com/UseGenevaSessionManagementForYourOwnNeeds.aspx), Dominick points out that if we don't want to retrieve these (expensive) claims from a data store on every request then we can make use of the SAM (SessionAuthenticationModule).  However, couldn't we just check to see if this claim already exists for the identity and then only fetch the claim if it doesn't exist?  Wouldn't this solve the performance concern?

public class Transformer : ClaimsAuthenticationManager
{
    public override IClaimsPrincipal Authenticate(string endpointUri, IClaimsPrincipal incomingPrincipal)
    {
     var claimName = "customClaimType";
     if(incomingPrincipal.Identities[0].Claims.Where(x => x.ClaimType == claimName).Count() <= 0)
  {
   // expensive operation
   var claimValue = [from expensive operation];
   
   incomingPrincipal.Identities[0].Claims.Add(new
     Claim(claimName, claimValue));
     }

        return incomingPrincipal;
 
    }
}

I don't understand why we have to resort to the SessionAuthenticationModule.  So I tried the above code on my local machine and I stepped through it to verify that for subsequent requests (after the initial one), the expensive operation doesn't get called.  Now I'm not sure if this will be the case in a load-balanced environment (web farm) or in a truly federated group involving multiple relying parties sharing a single-sign-on structure.

I would really appreciate an explanation that would help me understand this better.

Thanks!
-Karthi.

Answer 1

Is the above code in conjunction with WS-Federation - or a plain web app that does its own authentication?

(btw - this thread should be moved to the WIF forum)

---

Dominick Baier | thinktecture | http://www.leastprivilege.com

Answer 2

I'm actually using your (Dominick Baier's) IdentityServer as the STS - in conjunction with WS-Federation.

I did try to look for the WIF forum but I could not find it; I'll gladly move it if someone can point me to the location of the WIF forum.

Thanks!

-Karthi.

Answer 3

Then i am not sure i understand the question.

The WS-Fed module takes the incoming token, converts it to claims and runs that through the claims authentication manager. The outcome of that is turned into a cookie. From that point the session auth module parses the cookie to rehydrate the principal.

That's it.

---

Dominick Baier | thinktecture | http://www.leastprivilege.com

Answer 4

Thanks for the response Dominick.  I apologize for the long-winded question.  So I'm essentially asking, is it necessary to do what you suggest in this article:

http://www.leastprivilege.com/UseGenevaSessionManagementForYourOwnNeeds.aspx

Specifically, is it necessary to explicitly set the transformed principal into the session cookie after you add the claims in the derived ClaimsAuthenticationManager (Transformer) class?  Or is it sufficient to just add the claims and will the SessionAuthenticationModule automatically take care of putting the transformed token (with added claims and all) into the session cookie for you?

Thanks!

Answer 5

With the WS-Fed module - no. It does exactly that under the covers.

---

Dominick Baier | thinktecture | http://www.leastprivilege.com

Answer 6

Got it, I believe I misread your article :)  Totally missed the part about using Geneva 'for your own needs'!  Anyway, thanks for your patience - I understand this a whole better now...