locked
SAML tokens and caching

    Question

  • Hi All,

    I understand that ASP.NET Web applications can cache SAML tokens using the Microsoft.IdentityModel.Web.SessionAuthenticationModule (as explained in the "Federated Authentication Module Overview" section of the CHM of the Geneva framework SDK). What I don't understand though is this:
    1. How would tokens that are stored in a session work when the ASP.NET Web application is in a Web farm?
    2. Does the SessionAuthenticationModule expose a provider model, so that alternative caching providers can be plugged in and used instead?
    3. How does caching of SAML tokens happen for non-ASP.NET-Web-applications work?  Specifically, I would like to know what token caching approach(es) can be taken for stateless WCF services (that are also being load balanced) and need to function as RPs.  
    TIA!

    --

    Regards,

    Travis Spencer

    Tuesday, January 20, 2009 8:50 PM

Answers

  • Hi Travis

    Let me make sure I understand you.  As is, the SessionSecurityTokenHandler is suboptimal for use within Web farms.  (Oh, man, that sucks!)  To use it, I would need to modify it, so that it does not use ProtectedDataCookieTransform. Instead, I need to alter it to use RsaSignatureCookieTransform, a custom class that derives from CookieTransform or is based on CookieTransform. As you can see, I'm unclear as to whether or not I need to create a custom class "based off" of CookieTransform (by viewing the source and getting an idea of what it does) or by creating an inheritance relationship between CookieTransform and my custom class. 

    The RsaSignatureCookieTransform is a class that already exists in the Geneva Framework, and provides cookie integrity using RSA signature. You may either use that directly for your web-farm scenario, where all machines in the farm share the same RSA private key (generally associated with an X509 certificate).

    Alternatively, you may implement your own custom-CookieTransform (by deriving off of the CookieTransform class in the Geneva Framework), and implement a cookie integrity / confidentiality mechanism that will work in a web-farm scenario.

    Does this answer your question?

    I would love to see a sample of that. I'm just beginning to wrap my head around all this stuff, and I'm sure I don't have to tell you that it is a lot. A little example of what you're talking about would be much apprecaited.

    I will work with the appropriate folks to get you some example code in this regard, and post it as a follow-up.

    I would imagine that 90%+ of the users of Geneva framework are your enterprise customers, where Web farms are common place. I would encourage you guys to think seriously about this need and I would suggest that you do not RTM without built-in support for farms. Also, please, please, please do not neglect the caching story for the RPs that are WCF services. ATM, their doesn't seem to be much focus in the docs on WCF services that are RPs, so I'm concerned that the tooling-related work is being done primarily around ASP.NET Web apps. That is good, but nicities for WCF services will also be needed by the time this stuff RTMs IMHO.

    Thanks for the feedback. I definitely hear your concerns around (i) making the support for web farms easier and (ii) enabling caching extensibility for WCF services. These are two top-priority items that we are working on currently.

    • Marked as answer by Travis Spencer Tuesday, February 03, 2009 9:40 PM
    Tuesday, January 27, 2009 8:46 PM

All replies

  • Travis Spencer said:

    I understand that ASP.NET Web applications can cache SAML tokens using the Microsoft.IdentityModel.Web.SessionAuthenticationModule (as explained in the "Federated Authentication Module Overview" section of the CHM of the Geneva framework SDK). What I don't understand though is this:

    • How would tokens that are stored in a session work when the ASP.NET Web application is in a Web farm?

    After further reading, it seems that the entire SAML token is crammed into the cookie. If this is the case, there would not be any issue if subsequent requests were redirected to a different server in the farm, provided they all share the same private key. Is this correct?
    • Does the SessionAuthenticationModule expose a provider model, so that alternative caching providers can be plugged in and used instead?

    Unsure about this still, but it appears not. However, the FAM does raise an event where caching/persisting the token can be done.

    • How does caching of SAML tokens happen for non-ASP.NET-Web-applications work?  Specifically, I would like to know what token caching approach(es) can be taken for stateless WCF services (that are also being load balanced) and need to function as RPs.  

    After doing a bunch of reading over the last while, I haven't ran into any FAM-like analogy for use in WCF. Most of the material seems to be slanted toward RPs that are ASP.NET apps.  Any ideas about this or sources of info that others have found helpful?

    Wednesday, January 21, 2009 9:43 PM
  • Hi Travis,


    1. The SessionSecurityTokenHandler out of box is not ideal for a web farm. You would have to modify the SessionSecurityTokenHandler so that it didn't use the ProtectedDataCookieTransform and used RsaSignatureCookieTransform or a custom implementation based off the CookieTransform class instead.

    2. You could derive off of the SessionSecurityTokenHandler and using the constructor SessionSecurityTokenHandler(cookiesTranformsCollection, tokenCache) implement you own token cache.

    3. There are no out of box solutions for this scenario in Geneva Framework Beta 1.
    Wednesday, January 21, 2009 10:14 PM
  • Jason D. Shaw - MSFT said:

    Hi Travis,

    Hi Jason, Thanks for the reply. It is much appreciated.

    1. The SessionSecurityTokenHandler out of box is not ideal for a web farm. You would have to modify the SessionSecurityTokenHandler so that it didn't use the ProtectedDataCookieTransform and used RsaSignatureCookieTransform or a custom implementation based off the CookieTransform class instead.

    Let me make sure I understand you.  As is, the SessionSecurityTokenHandler is suboptimal for use within Web farms.  (Oh, man, that sucks!)  To use it, I would need to modify it, so that it does not use ProtectedDataCookieTransform. Instead, I need to alter it to use RsaSignatureCookieTransform, a custom class that derives from CookieTransform or is based on CookieTransform. As you can see, I'm unclear as to whether or not I need to create a custom class "based off" of CookieTransform (by viewing the source and getting an idea of what it does) or by creating an inheritance relationship between CookieTransform and my custom class.

    2. You could derive off of the SessionSecurityTokenHandler and using the constructor SessionSecurityTokenHandler(cookiesTranformsCollection, tokenCache) implement you own token cache.

    I would love to see a sample of that. I'm just beginning to wrap my head around all this stuff, and I'm sure I don't have to tell you that it is a lot. A little example of what you're talking about would be much apprecaited.

    3. There are no out of box solutions for this scenario in Geneva Framework Beta 1.

    I would imagine that 90%+ of the users of Geneva framework are your enterprise customers, where Web farms are common place. I would encourage you guys to think seriously about this need and I would suggest that you do not RTM without built-in support for farms. Also, please, please, please do not neglect the caching story for the RPs that are WCF services. ATM, their doesn't seem to be much focus in the docs on WCF services that are RPs, so I'm concerned that the tooling-related work is being done primarily around ASP.NET Web apps. That is good, but nicities for WCF services will also be needed by the time this stuff RTMs IMHO.

    --

    Thanks Again,

    Travis Spencer
    Thursday, January 22, 2009 6:48 PM
  • Hi Jason,

    Any clarification you can provide on the followup questions above would be much appreciated.

    --

    Regards,

    Travis Spencer

     

    Tuesday, January 27, 2009 5:07 PM
  • Hi Travis

    Let me make sure I understand you.  As is, the SessionSecurityTokenHandler is suboptimal for use within Web farms.  (Oh, man, that sucks!)  To use it, I would need to modify it, so that it does not use ProtectedDataCookieTransform. Instead, I need to alter it to use RsaSignatureCookieTransform, a custom class that derives from CookieTransform or is based on CookieTransform. As you can see, I'm unclear as to whether or not I need to create a custom class "based off" of CookieTransform (by viewing the source and getting an idea of what it does) or by creating an inheritance relationship between CookieTransform and my custom class. 

    The RsaSignatureCookieTransform is a class that already exists in the Geneva Framework, and provides cookie integrity using RSA signature. You may either use that directly for your web-farm scenario, where all machines in the farm share the same RSA private key (generally associated with an X509 certificate).

    Alternatively, you may implement your own custom-CookieTransform (by deriving off of the CookieTransform class in the Geneva Framework), and implement a cookie integrity / confidentiality mechanism that will work in a web-farm scenario.

    Does this answer your question?

    I would love to see a sample of that. I'm just beginning to wrap my head around all this stuff, and I'm sure I don't have to tell you that it is a lot. A little example of what you're talking about would be much apprecaited.

    I will work with the appropriate folks to get you some example code in this regard, and post it as a follow-up.

    I would imagine that 90%+ of the users of Geneva framework are your enterprise customers, where Web farms are common place. I would encourage you guys to think seriously about this need and I would suggest that you do not RTM without built-in support for farms. Also, please, please, please do not neglect the caching story for the RPs that are WCF services. ATM, their doesn't seem to be much focus in the docs on WCF services that are RPs, so I'm concerned that the tooling-related work is being done primarily around ASP.NET Web apps. That is good, but nicities for WCF services will also be needed by the time this stuff RTMs IMHO.

    Thanks for the feedback. I definitely hear your concerns around (i) making the support for web farms easier and (ii) enabling caching extensibility for WCF services. These are two top-priority items that we are working on currently.

    • Marked as answer by Travis Spencer Tuesday, February 03, 2009 9:40 PM
    Tuesday, January 27, 2009 8:46 PM
  • Hi Travis,

    For #3, you might want to take a look at this post, http://weblogs.asp.net/cibrax/archive/2006/03/27/441227.aspx
    I wrote it some time ago, but it is still useful for caching SAML tokens on the client side.

    Regards,
    Pablo.
    Pablo Cibraro - http://weblogs.asp.net/cibrax
    Thursday, February 12, 2009 4:29 PM
  • Geneva Team or anyone else,

     I'm really hoping that you can post the sample (using RsaSignatureCookieTransform). I'm having very similar issues.
    • Proposed as answer by Michel Fleitas Friday, October 09, 2009 1:49 PM
    Thursday, February 19, 2009 4:43 PM
  • Hi Pablo,

    I have had a look at your post "http://weblogs.asp.net/cibrax/archive/2006/03/27/441227.aspx". I have following question:-

    I understand your implementation except that I can't understand why do you need "innerProvider" in "CustomIssuedSecurityTokenProvider". I suppose the innerProvider will contain the IssuedSecurityTokenProvider object and "IssuedSecurityTokenProvider" is the base class of "CustomIssuedSecurityTokenProvider". So in the GetTokenCore method instead of making use of "this.innerProvider.GetToken(timeout)", a call to base.GetTokenCore(timeout) can be used. If we follow this approach we don't even need to worry about openning the innerProvider or closing it in dispose.

    Your help is much appreciated.

    Cheers,

    Syed

    Thursday, April 29, 2010 11:04 AM