Session Management + Custom Authorization setup RRS feed

  • Question

  • User-1322861770 posted
    G'day,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>I'm a software developer from a company who has written a series of vb.net VS2005 (.net  framework 2.0) web application for a client. The solutions include a SQL Server Reporting Services web application. We developed a major web site with 3 sub applications via various developers using windows XP, Vista 64 (quad core) and Vista 32 (quad core) development environments.  At the developer end, we implemented a custom windows forms authentication code to interact with the sites security and our codes business layers security requirements. The solutions use the CSLA framework 3.0.3.<o:p></o:p>It worked in development and on a test site, so we tried to deploy to a test site on the customers web farm.  The customer has configured the web farm as 2 windows 2008 IIS 7 load balanced x64 servers with a common metabase.  Dare I say it but the deployment failed terribly! Here is what we learnt.<o:p></o:p>Lessons learnt for the first 3 failed deployments<o:p></o:p>
    1. We needed to run CASPOLE on the network shared used by both web servers, so .net security would run the web application (the web farm uses a single network share as web site source). See KB 320268<o:p></o:p>
    2. We had to get the web.config files upgraded to IIS7 compatible ones.  This seemed counter intuitive as the sites didn’t seem to require this during development on Vista IIS machines.<o:p></o:p>
    3. Running sub applications was a mistake, for a range of reasons (master pages, web.sitemaps and authentication and lack of access to the IIS Management tool as an external consultant), so we eventually removed this approach. We now just FTP deploy to the client.  Prior to launch we do a mini deploy to a local web server and delete lots of web.config files in the sub applications and move files from \sub app\bin\ directories up to the parent \bin\ directory.<o:p></o:p>
    4. We found did a little merry go round with Application Pools pipeline settings “.net Classic” vs “Integrated Pipeline”.  Eventually we found a recommendation to use integrated pipeline.<o:p></o:p>
    5. We definitely needed code in the global.asax “Application_Error” method to help identify some missing installation components for Microsoft SQL Server reporting services viewer control.  We aren’t sure which service pack is required to match our development environment.  Download from Microsoft<o:p></o:p>
    6. If you use a custom build Forms Authentication solution, don’t forget to add code the global.asax to handle this style of authentication.  We are a little confused on the actual event to use as there was conflicting recommendations between Application_AcquireRequestState (CSLA recommendation) or Application_AuthenticateRequest (a number of online articles).<o:p></o:p>
    7. There were some obvious human factor issues.  <o:p></o:p>
      1. We assumed that the solution working in Vista IIS would translate to the customer Windows 2008 web farm with little or no effort/change and we were wrong.  <o:p></o:p>
      2. We ignored exception details. We should have read some of the details from the error messages that came up during these failures.  We didn't usually get beyond the first 3 lines and before shooting off to find help online and got frustrated.<o:p></o:p>
      3. We don't understand how web farms are setup and if there are settings that affect our application.  We assumed the web farm would just do its job.  <o:p></o:p>
      4. We also made the assumption that Microsoft would have best practice documents for moving to IIS7 web farms for .net solutions, which we couldn't find. We eventually used two checklists, Microsoft Securing ASP.net checklist and a Breaking changes Blog<o:p></o:p>

    So that was 1.5 weeks to learn these lessons.  At this point we could get up normal non authenticated pages.  The customer was slightly annoyed.

    <o:p></o:p>Authentication & session state Issues outstanding<o:p></o:p>The non authenticated parts of the site work.  We now have to get the authenticated application components to work.  Here is what happens to a person trying to logon.<o:p></o:p>
    1. You logon with a bad user/password and it returns that failed request.<o:p></o:p>
    2. You logon with a good user/password and it redirects you back to the logon page (with the same redirect query string?)<o:p></o:p>
    3. You logon with a good user/password and it occasionally redirects to the working page as you would expect and you can get a page or two more clicks before you’re asked to re logon.<o:p></o:p>
    We believe that the authentication cookie is not getting passed between the servers on the web farm, because if we set the web.config files use the cookieless=”AutoDetect” we can see the URL cookie changing e.g. http://www.DevelopersStressedOut.com.au/(X(1)S(qybi2gme3rpzgdvgh0s1k4m3)F(NQkjRKkO5q0UkgFcAx7YNKWEmfQ5aLviqd4hsVTLIdyoQ43yE6GATxZJq0n9WXy8qEtXagQmiGsWdnX4onlLn9B9JLrPcPWn0k9YKVS3CYOPzrM55BO3lSy45q1iykyT0))/Default.aspx? <o:p></o:p>http://www.DevelopersStressedOut.com.au (X(1)S(eijtti55e0zvambeu5imdjzf))/UserLogon.aspx?ReturnUrl=Default.aspx?<authentication mode="Forms"><o:p></o:p><forms loginUrl="~/UserLogon.aspx" defaultUrl="~/Default.aspx" name=".IimsWebAuth" timeout="60" enableCrossAppRedirects="true" cookieless="AutoDetect" requireSSL="false" slidingExpiration="true" protection="All" />
    <o:p></o:p>From our perspective, this problem seems to be broken into 3 issues and we have spent another man week trying to address and resolve them, with little luck.  <o:p></o:p>
    1. Session management configuration on a web farm<o:p></o:p>
    2. Customized Forms authentication setup.<o:p></o:p>
    3. General trouble shooting of deployed web applications (ones that we don’t administer)<o:p></o:p>


    <o:p></o:p>Are we on the right track? And can anyone see what we have missed in our setup so we can fast track the solution into the customer’s web server?<o:p></o:p><o:p> </o:p>Here are some basic details of the Authentication and session management settings in our application.<o:p></o:p>Forms Authentication setup<o:p></o:p>Web.config<o:p></o:p><authentication mode="Forms"><o:p></o:p><forms loginUrl="~/UserLogon.aspx" defaultUrl="~/Default.aspx" name=".IimsWebAuth" timeout="60" enableCrossAppRedirects="true" cookieless="AutoDetect" requireSSL="false" slidingExpiration="true" protection="All" />
    <o:p></o:p>Global.asax <o:p></o:p>Protected Sub Application_AcquireRequestState(ByVal sender As Object, ByVal e As System.EventArgs)<o:p></o:p>        Dim principal As System.Security.Principal.IPrincipal<o:p></o:p>        Try<o:p></o:p>            principal = _<o:p></o:p>          CType(Session("CslaPrincipal"),System.Security.Principal.IPrincipal)<o:p></o:p>        Catch<o:p></o:p>            principal = Nothing<o:p></o:p>        End Try<o:p></o:p>        If principal Is Nothing Then<o:p></o:p>            ' didn't get a principal from Session, so<o:p></o:p>            ' set it to an unauthenticted PTPrincipal<o:p></o:p>            Dim security As New Iims.BL.Security.IimsPrincipal<o:p></o:p>            security.LogOff()<o:p></o:p>        Else<o:p></o:p>            ' use the principal from Session<o:p></o:p>            Csla.ApplicationContext.User = principal<o:p></o:p>        End If<o:p></o:p>    End Sub<o:p></o:p>App_Code class.
    Public Class IimsMembershipProvider
        Inherits MembershipProvider<o:p></o:p>
        Public Overrides Function ValidateUser( _
          ByVal username As String, ByVal password As String) As Boolean
            Dim myPrinciple As New Iims.BL.Security.IimsPrincipal<o:p></o:p>
            If myPrinciple.LogOn(username, password) Then
                System.Web.HttpContext.Current.Session("CslaPrincipal") = Csla.ApplicationContext.User
                System.Web.HttpContext.Current.Session("UserID") = CType(Csla.ApplicationContext.User.Identity, Iims.BL.Security.IimsIdentityExtened).UserID<o:p></o:p>
                Return True
                Return False
            End If<o:p></o:p>
        End Function<o:p></o:p>#Region "Not Implemented Members – is every other method"<o:p></o:p>    Public Overrides Property ApplicationName() As String
                Throw New Exception("The method or operation is not implemented.")
            End Get
            Set(ByVal value As String)
                Throw New Exception("The method or operation is not implemented.")
            End Set
        End Property<o:p></o:p>
    .....CUT, as all the rest are not implemented.<o:p></o:p>#End Region<o:p></o:p>End Class<o:p></o:p>Session Management Setup<o:p></o:p>We setup SQLState database on our SQL 2005 enterprise x64 server and configured the site to point to it.<o:p></o:p>Web.config<o:p></o:p><!-- This setting required for web farms and because we have view/session state enabled<o:p></o:p>                       <o:p></o:p>                       Generated the following line at http://www.aspnetresources.com/tools/keycreator.aspx<o:p></o:p>--><o:p></o:p>              <machineKey validationKey="CB108688322F257..cut for security reassons" decryptionKey="2A29…cut also for security reasons" validation="MD5" /><o:p></o:p>              <!--   Production Version<o:p></o:p>                           Only (or if a developer has access to a SQL Server with session information<o:p></o:p>                           Created .net 2.0 SQL Server based session variables.<o:p></o:p>       %Windows%\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe in command line mode to create an ASPState database.<o:p></o:p>              --><o:p></o:p>              <sessionState allowCustomSqlDatabase="false" cookieless="UseCookies" cookieName="Iims.SessionID" <o:p></o:p>                                    mode="SQLServer" sqlConnectionString="Server=SRVR-123;User ID=User123;Password=p@ssw0rd123" <o:p></o:p>                                    useHostingIdentity="false" sqlCommandTimeout="60" timeout="60" /><o:p></o:p><o:p> </o:p>


    Sunday, June 1, 2008 8:59 PM

All replies

  • User113421904 posted

    Are we on the right track? And can anyone see what we have missed in our setup so we can fast track the solution into the customer’s web server? Here are some basic details of the Authentication and session management settings in our application.Forms Authentication setup

    Use sql server as sessionstate mode could make web garden serve requests without session-data loss when one node fails. We does have KB article shows you the configuration step-by-step:


    However the authentication seems to be handled by the CSLA framework itself according to the code in Global.asax. Could you explain more details about the authentication in CSLA? To make sure the authentication works, you can try it with ASP.NET 2.0 Membership:


    Thursday, June 5, 2008 8:08 AM
  • User-1322861770 posted

    Thanks for the response. The Code to handle authentication is a simple class that inherits from iPrinciple to communicate with a SQL Server database with a custom user/role table structure.  We have unit tested this and confirmed it works and correctly populates the user and role(s) credientials.

    We removed all authentication from the web solution to continue acceptance testing with the customer and then lots of things just worked.  Ruling out a whole series of configuration concerns in the process.

    Further research of the problem seems to be a server configuration issue.  None of the security roles on the IIS7 server are installed.  The customer has just asked which Security Role matches "Forms Authentication" as there doesn't seem to be a exact match.

    If the IIS installed roles (missing) does turn out to be the problem, I must admit to being a little annoyed (2 weeks of web.config and application code changes) as why a more meaning full error wasn't displayed to the user during authentication or why the IIS Management tool wouldn't stop users from trying to use features that are not installed.


    Thursday, June 5, 2008 9:43 PM
  • User-1322861770 posted

    And we finally found the last source of our application issues.  The subdomain for the web site had an underscore in it.  Microsoft IE5 on has security patches that cause IIS to constantly recreate SessionID's. This just breaks custom forms authentication solutions! Other browswers like Firefox, work as you might expect.

    So in the end the migration to IIS7 was a number of security and web configuration issues, but 3-4 weeks was spent learning how to navigate the new IDE's, changing, testing and trying to determine why a complex farm/SQL Database application didn't work on IIS7 was because the customers IIS manager wasn't aware of the domain underscore issue.  We found the that answer by complete fluke!  During this experience, our non technical customers lost a significant amount of faith in our recommendations to use the new Microsoft technology.

    We now will not upgrade microsoft technology, until both our staff and the customers staff have had appropriate training on the new technology IDE's, because the costs/time/frustration penalties to do other wise is too much.

    Wednesday, September 17, 2008 7:22 AM