locked
Azure application on multiple instances, what to take care of? RRS feed

  • Question

  • Hello!
    My aim is to distribute an azure application, an ASP.NET MVC3 project, on multiple instances. Therefore I have several questions regarding the technical pitfalls I want to avoid.
    1. From the programmer's perspective, what has to be taken into account?
    Okay, the application needs to be stateless -  I'm not sure my authentication mechanism is suitable. It uses claims-based-authentication via windows identity foundation and looks like this:
    ______________________
    void Application_PostAuthenticateRequest(....)
    {
    	IPrincipal current = Thread.CurrentPrincipal;
    	if (current != null)
        {
    		IPrincipal result = AuthorizationManager.CreatePrincipal((IClaimsIdentity)current.Identity);
    		HttpContext.Current.User = result;
    		Thread.CurrentPrincipal = result;
        }
    }
    ______________________
    The AuthorizationManager.CreatePrincipal method extracts claims of the identity, looks up rights/roles in a xml file and creates a new (generic) principal which is easier to use than the original claims based one.
    Afterwards, on every page that needs authentication it is just:
    ______________________
    IPrincipal p = Thread.CurrentPrincipal;
    p.IsInRole("rolesFromXml");
    ______________________
    Could this lead to problems on multiple instances? Until now, the redirect to the intranet's security token service is only done once at the first page load, would be nice if this could be retained.
    2. I know that there is a beta for load balancing at the moment, the traffic manager CTP. But without using the beta, how is it done at the moment, I heard about a simple load balancer that does round robin, is that correct? I also heard it does not support sticky sessions, could this be a problem regarding question 1 above?
    Thank you!
    edit: don't know why syntax highlighting doesn't work, same for new lines. Sorry for that. Inserted some lines to make it readable.




    • Edited by tryoutazure Tuesday, October 25, 2011 9:04 AM
    Tuesday, October 25, 2011 8:40 AM

Answers

  • Hi again,

    If you use WIF the stright forward way (Right click on the web project -> Add STS Reference -> point to your ACS STS -> next -> next -> OK -> next ..[whatever all defaults]), by default you are using the SAM (Session Authentication Module). And in that case you will need to add the 3 lines of code so the underlying WIF will handle everything for you. Everything regarding authentication. And I don't think WIF is about session management. WIF/ACS is about identities.

    Session is other story, and regardless of what technique you are using for authentication, if you use Sessions in your application, you'll have to find a way to take the session out of the process (which is default configuration for ASP.NET). Then you can use either Windows Azure AppFabric Cache, or you can use the Azure Providers to put your session in SQL Azure.

    Thursday, October 27, 2011 4:46 AM

All replies

  • Hi,

    Do you want to use passive federation or active federation?

    For passive federation (the browser only maintains a session cookie), you will run into problems with multiple instances, similar to the problem you encounter with sessions. In this case, you can save the session data in AppFabric cache, which works for multiple instances.

    For active federation (the browser uses JavaScript to invoke controllers, and send the security token in the Authorization header), you do not need to worry about multiple instances.

     

    Best Regards,

    Ming Xu.


    Please mark the replies as answers if they help or unmark if not.
    If you have any feedback about my replies, please contact msdnmg@microsoft.com.
    Microsoft One Code Framework
    Wednesday, October 26, 2011 3:41 AM
  • Using WIF with Windows Azure is pretty much OK. The short story is: you have to encrypt/decrypt session cookies with a service certificate (X.509). And the easiest way to achieve this is to use the X.509 certificate of the server used for the HTTPS (we don't do WIF/ACS over plain HTTP, right ;)).

    An example of how to do that can be found in the Identity Training Kit under

    [PATH_TO_YOUR_IDENTITY_TRAIING_KIT]\Labs\WindowsAzureAndPassiveFederation

    I did it for some of mine deployments. It works :)

    Hope this helps.

    Wednesday, October 26, 2011 7:51 AM
  • Thanks to both of you, I'm a little bit confused now. MingXu says, passive federation leads to problems and I need to use the appfabric cache. I use passive federation and I remember this blog post , I think it describes what Anton said, doesn't it? The app fabric cache isn't mentioned there (it cannot be mentioned since the blog post hasn't anything to do with azure, but with multiple instances).

    Thanks


    • Edited by tryoutazure Wednesday, October 26, 2011 8:37 AM
    Wednesday, October 26, 2011 8:36 AM
  • Hi,

    If you don’t use SessionAuthenticationModule, you will be fine even in passive federation mode. But if you use SessionAuthenticationModule, you must handle session the same way you handle normal ASP.NET session: store session data in a common place such as AppFabric cache. Without SessionAuthenticationModule, each time the client invokes the service, it must go through the STS again to obtain a new token. STS may have session enabled and the user doesn’t have to type the credential again. But the performance is still not good because the client must first contact STS and then redirected to your service.

     

    Best Regards,

    Ming Xu.


    Please mark the replies as answers if they help or unmark if not.
    If you have any feedback about my replies, please contact msdnmg@microsoft.com.
    Microsoft One Code Framework
    Wednesday, October 26, 2011 10:37 AM
  • Thanks. Regarding the SessionAuthenticationModule, I found this:

    ...you could come up with some server-local caching strategy – or use the SessionAuthenticationModule to serialize the IClaimsPrincipal after transformation to a cookie. The module will then reconstruct the IClaimsPrincipal on subsequest requests and set it as the current principal for the ASP.NET application.

    This sounds like I do not have to store session data on serverside, do I? If yes, why this cookie processing is so complicated (serialize token to cookie instead of saving a session id in cookie and store token on the server). On another subsequent azure instance, can't the whole token get recovered from the cookie instead of using the appfabric cache?

    For now, I'm only interested in recovering the token from other azure instances without having to visit the STS again, so forget about the GenericPrincipal from my start post for a moment.

     

    Thanks again







    • Edited by tryoutazure Wednesday, October 26, 2011 12:23 PM
    Wednesday, October 26, 2011 11:56 AM
  • Hi again,

    If you use WIF the stright forward way (Right click on the web project -> Add STS Reference -> point to your ACS STS -> next -> next -> OK -> next ..[whatever all defaults]), by default you are using the SAM (Session Authentication Module). And in that case you will need to add the 3 lines of code so the underlying WIF will handle everything for you. Everything regarding authentication. And I don't think WIF is about session management. WIF/ACS is about identities.

    Session is other story, and regardless of what technique you are using for authentication, if you use Sessions in your application, you'll have to find a way to take the session out of the process (which is default configuration for ASP.NET). Then you can use either Windows Azure AppFabric Cache, or you can use the Azure Providers to put your session in SQL Azure.

    Thursday, October 27, 2011 4:46 AM
  • I give thought on my post above and noticed that I was not accurate enough. Of course, identity management and session management are different things. What I meant: is it possible to "misuse" an identity cookie (= a serialized token from STS with the help of SessionAuthenticationModule) to create some kind of session-like behaviour, but without having to store information on server side? 
    How that could work from my point of view, 2 steps:
    1.
    Such an "identity cookie" that is generated by SAM still contains the whole information of an identity (claims for example). On subsequent requests, the server can look up this cookie instead of doing the redirect thing with the STS again. For this mechanism, nothing has to be stored on the serverside. 
    Okay, I know that this hasn't to do something with "real sessions", but in my opinion, it is definetly some kind of a session, because the serverside can recognize an identity without storing information about it. I know that it is now necessary to to the mapping between such an identity and my xml-autorization file on each request instead on the first request only.
    Are my thoughts correct so far? In short: no server side session management needed when misusing identity cookies and do the authorization on each request from scratch.
    2. If the above is correct, I could implement an custom AuthenticationManager in order to store my autorization data from the xml file as a claim in the cookie, so I could avoid doing autorization mapping from scratch on each request.
    Thanks :)
    Friday, November 4, 2011 4:02 PM