Exporter (0) Imprimer
Développer tout
Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Forms-Based Authentication with SQL Server On-Premises

Mis à jour: octobre 2011

Author: http://msdn.microsoft.com/fr-fr/library/hh307537.aspx

Image référencée

Learn more about RBA Consulting.

Introduction

Summary: This article explains how to implement three different models for incorporating forms-based authentication in ASP.NET applications that are hosted on the Windows Azure platform, and provides guidance on when to use each model.

Forms-based authentication enables ASP.NET applications to use a custom logon form to authenticate a user's credentials (user name/password). All unauthenticated requests are redirected to the logon page, where the users submit their credentials for authentication. If the user's credentials are authenticated by the ASP.NET application, it issues a token that contains a key that reestablishes the user's identity on subsequent requests. Forms-based authentication is a model familiar to many developers who have created on-premises ASP.NET applications. This article demonstrates how to implement forms-based authentication for ASP.NET applications that are hosted on the Windows Azure platform. The article covers the following scenarios.

  • Authentication that uses an on-premises Microsoft SQL Server and Windows Azure Connect. (For more information about Windows Azure Connect, see the "Windows Azure Connect" section of the article Windows Azure Virtual Network.)

  • Authentication that uses SQL Azure. (For information about SQL Azure, see the SQL Azure home page on MSDN.)

  • Authentication that uses Windows Azure storage. (For more information about Windows Azure storage, see the article Windows Azure Storage.)

As it examines each of these scenarios, the article will define the authentication model associated with the scenario, provide guidance on when the model should be used, and show how to implement the model.

Forms-Based Authentication with SQL Server On-Premises

The first model uses the SqlMembershipProvider and SqlRoleProvider to authenticate users of an ASP.NET web application that is hosted in Windows Azure against data that is stored in an on-premises SQL Server database.

When to Use the Model

This section looks at the benefits and concerns associated with this model, and provides guidance on when the model should be used.

Benefits

  • The SqlMembershipProvider and the SqlRoleProvider ship with the .NET Framework. This means that these providers are extensively tested and officially supported by Microsoft. There is also an considerable amount of documentation and samples available to help developers.

  • This model is no different from a standard on-premises implementation, which means that there are no additional effort/skills required.

  • ASP.NET applications hosted in Windows Azure can use existing user stores, and do not need to implement a strategy to move user data to a new storage mechanism.

  • User data that is stored in SQL Server is relational, which makes it easily consumable by other applications and reporting frameworks.

  • If this model is implemented with an existing on-premise SQL Server, there is no additional cost incurred.

  • This model is not subject to the current size limitations imposed by SQL Azure, which is discussed in the next section.

  • There are no per transaction costs associated with using SQL Server for the user data store.

Concerns

  • Windows Azure Connect does not support connectivity to clustered and load-balanced resources. If an existing SQL infrastructure is clustered for High Availability (HA), this model will not work.

  • When authentication is performed, credentials are passed over the wire from the client to the ASP.NET application. To prevent these credentials from being compromised, they should be protected during the authentication process by using SSL to secure the communication channel between the client and the server. The communication from the ASP.NET application to SQL Server must also be taken into account. The tabular data stream (TDS) that connects the ASP.NET application and the SQL Server database should be encrypted to ensure that data is not compromised as it travels to and from the Windows Azure data center.

  • In cases where an existing user data store does not exist, a new store will have to be built. This means that there is an additional, one-time, administrative cost, which could be significant depending on the number of users in the system.

  • This model does not allow for run-time changes to authentication logic. As a result, if the ASP.NET application's authentication code requires an update, the application will have to be re-deployed to the Windows Azure environment.

  • Latency is another consideration. To authenticate and authorize a user in this model, a request has to go from the client's browser, to the Windows Azure data center, to the on-premises SQL Server. This additional hop means that authentication requests incur some latency. The bandwidth coming into and out of the network on which the SQL Server is hosted could also introduce latency. If, for example, the SQL Server is connected to a network with a DSL Internet connection, authentication requests will be served more slowly than if the server was connected to a network with a T1 connection.

Guidance

  • ASP.NET applications with authentication and authorization requirements that can be defined in terms of user names and roles are a good fit for this model. User names and roles are supported by the SqlMembershipProvider and the SqlRoleProvider. If the application has more advanced authentication and authorization requirements, select a different security model.

  • If the ASP.NET application requires that the user data be analyzed, then this model may be a good fit, because relational databases lend themselves to complex analysis.

  • This model does not support multiple applications, so it is a good choice if the authentication logic is limited to the scope of the ASP.NET application and does not have to be shared with other applications.

  • This model works well when an existing ASP.NET application that uses the SqlMembershipProvider and the SqlRoleProvider, and that stores user data in an existing on-premises SQL Server database, is being moved to the Windows Azure environment. Given that the application is already using these established and well-tested providers, it makes sense to keep them in place.

The Model Defined

The following figure illustrates how forms-based authentication between an ASP.NET application in Windows Azure and an on-premises SQL Server database works.

Écran référencé

The client's browser connects to the ASP.NET application to perform authentication. The connection is made over port 443, which is secured with HTTPS and SSL. All non-secure communication between the client's browser and the ASP.NET application use HTTP, and communicate through port 80.

The ASP.NET application's Web.config file specifies the following information.

  • The application's authentication mode is set to Forms.

  • The logon page that is used by the application for forms authentication.

  • The membership provider is set to SqlMembershipProvider.

  • The role provider is set to SqlRoleProvider.

  • The connection string that is used to connect to the on-premises SQL Server user store.

The Windows Azure web role's service configuration stores the activation token that is required by Windows Azure Connect. For details on how Windows Azure Connect works to connect Windows Azure and on-premises resources, see the article Overview of Windows Azure Connect on MSDN.

One Windows Azure Connect local endpoint is installed in the Windows Azure web role, and another is installed in the on-premises SQL Server. These endpoints enable Windows Azure and SQL Server to communicate.

The SQL Server database stores the following pieces of information.

  • User data such as user names and encrypted passwords that are used by the ASP.NET application.

  • The names of roles that are used by the ASP.NET application to secure application resources.

  • The associations of users with roles.

The following diagram shows the schema that is used by the SQL Server database to store this information.

Écran référencé

Windows Azure Connect enables the hosted ASP.NET application to communicate with the on-premises SQL Server user store. It uses port 1433, just as it would with any standard SQL database. The tabular data stream (TDS) that is used for application-to-database communication is encrypted to provide an additional layer of security. For more information about TDS, see the article Network Protocols and TDS Endpoints on MSDN.

One important thing to note is that Windows Azure Connect does not support connectivity to clustered and load-balanced resources. If an existing SQL infrastructure is clustered for HA, this model will not work. An alternative approach in this case would be to configure to a new single node SQL installation. However it must be kept in mind that such an installation exposes a single point of failure.

How to Implement the Model

This section shows you how to implement forms-based authentication with an on-premises SQL Server. The section assumes that you already have an instance of SQL Server 2008 R2 installed on-premises.

Configuring the Database Server

This section shows you how to configure SQL Server 2008 R2 for remote access. If the SQL Server 2008 R2 instance is already configured for remote access, you can either walk through the steps in this section to verify that the configuration is correct, or you can skip ahead to the Preparing the Database section.

  1. Open Microsoft SQL Server Management Studio and connect to the server that will host the database.



    Écran référencé

  2. In the Object Explorer, right-click the server node and select Properties.



    Écran référencé

  3. Select Security and make sure that SQL Server and Windows Authentication mode (also known as mixed mode) is selected.



    Écran référencé

  4. Select Connections and ensure that the Allow remote connections to this server option is selected. Click OK.



    Écran référencé

  5. Open SQL Server Configuration Manager.



    Écran référencé

  6. The next configuration step requires that the SQL Server instance has the TCP/IP protocol enabled. Expand the SQL Server Network Configuration node, select the instance of SQL Server that hosts the database, and ensure that the TCP/IP protocol is enabled. If it is not enabled, right-click the TCP/IP protocol and click the Enable option.



    Écran référencé

  7. Right-click the TCP/IP protocol and select Properties.



    Écran référencé

  8. Click the IP Addresses tab and scroll to the bottom of the screen. The last entry in the list should be IP All. Delete any entries in the TCP Dynamic Ports field, and change the TCP Port field to 1433. Click OK.



    Écran référencé

  9. Click the SQL Server Services node in the SQL Server Configuration Manager, right-click the instance being used, and click Restart.



    Écran référencé



    SQL Server is now configured to allow inbound traffic on port 1433. If port 1433 is blocked by the firewall on the corporate network/router and/or the Windows Firewall on the database server, you will either need to add a rule to the firewall to allow incoming traffic on port 1433, or change the TCP Port in step 8 to one that the firewall can accept incoming traffic on.

Preparing the Database

You must decide whether to use an existing on-premises SQL Server user store, or create a new one. This section shows you how to create a new user store. If you plan on using an existing user store, you can skip ahead to the Configuring Windows Azure Connect (pre-Deployment) section.

  1. Open Microsoft SQL Server Management Studio and connect to the server on which the database will be created.



    Écran référencé

  2. Right-click the Databases folder in the Object Explorer and select New Database.



    Écran référencé

  3. In the New Database dialog box, specify a database name as well as any other options you may need. Click OK.



    Écran référencé

  4. After the database is created, the user, role, and membership schema need to be installed in the database. You can perform this installation by using the Aspnet_regsql.exe command line tool. The first step to using Aspnet_regsql.exe is to open a command prompt as an administrator.

  5. Next, change the working directory to the directory where the Aspnet_regsql.exe tool is located.



    For 32-bit machines, use the following script.



    cd %windir%\Microsoft.NET\Framework\v4.0.30319
    
    For 64-bit machines, use the following script.



    cd %windir%\Microsoft.NET\Framework64\v4.0.30319
    
  6. After the working directory has been changed to the appropriate location, run Aspnet_regsql.exe with the following script. It installs the schema into the on-premises SQL Server database.



    aspnet_regsql -S [your instance of sql server] -d [your database name] -E -A mr
    
  7. To verify that the installation was successful, use SQL Management Studio to log back into SQL Server. Expand the Tables node of the database. The following tables should now be visible.



    • dbo.aspnet_Applications

    • dbo.aspnet_Membership

    • dbo.aspnet_Roles

    • dbo.aspnet_SchemaVersions

    • dbo.aspnet_Users

    • dbo.aspnet_UsersInRoles



      Écran référencé

Configuring Windows Azure Connect (pre-Deployment)

After you have configured the SQL Server database so that it can be used by the SqlMembershipProvider and the SqlRoleProvider, configure Windows Azure Connect.

  1. Log on to the Windows Azure management portal, which is located at http://manage.windowsazure.com.

  2. Click the Virtual Network option on the toolbar on the left side of the screen.



    Écran référencé

  3. If the Virtual Network option is not enabled, you will need to enroll in the Windows Azure Connect program. To do so, click the Home option on the toolbar, select the Beta Programs option, and apply for access to the Windows Azure Connect program.



    Écran référencé

  4. Under the Connect node on the toolbar on the left side of the screen, select the subscription that you plan to use to host your ASP.NET application.



    Écran référencé

  5. In the Configure section of the toolbar at the top of the screen, click the Install Local Endpoint button.



    Écran référencé

  6. Copy the link that is displayed in the dialog box to the clipboard.



    Écran référencé

  7. Log on to the machine that hosts the SQL Server instance that contains the ASP.NET database.

  8. Launch a browser, using the URL that you obtained in step 6.

  9. When prompted to run or save wacendpointpackage.exe from waconnect.blob.core.windows.net, select RUN. You cannot save the executable and install it later because it includes an activation token.

  10. The Windows Azure Connect Endpoint Installation starts. Select the language you want to use, and click Next.



    Écran référencé

  11. Accept the terms of use, and click Next.



    Écran référencé

  12. The wizard downloads and installs the endpoint on the local machine.



    Écran référencé
  13. When the installation completes, click Finish.



    Écran référencé

  14. After the installation completes, an icon for Windows Azure Connect appears in the system tray.



    Écran référencé

  15. Double-clicking the icon launches a dialog box that displays information about the Windows Azure Connect endpoint that runs on the machine.



    Écran référencé

    The endpoint is still not configured to connect to any instances that are running in Windows Azure. This configuration occurs after the ASP.NET application is deployed.

  16. At this point, the initial configuration is complete. However, before proceeding to the next section, you should get a Windows Azure Connect activation token so that you can configure your ASP.NET web role correctly. To get the token, go back the Virtual Network portion of the management portal, and click the Get Activation Token button in the Configure portion of the toolbar at the top of the screen.



    Image référencée

  17. Copy the activation token that appears in the dialog box to the clipboard.



    Écran référencé

Creating the ASP.NET Application

Now that you have configured SQL Server, and Windows Azure Connect on the machine that hosts the database, the next step is to create the ASP.NET application that will use the database.

  1. Open Microsoft Visual Studio® and create a new Windows AzureProject.



    Écran référencé

  2. Add an ASP.NET Web Role to the project.



    Écran référencé

  3. Open the ASP.NET Web Role project's Web.config file and find the following entry.



    <add name="ApplicationServices" connectionString="data
    source=.\SQLEXPRESS;Integrated
    Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User
    Instance=true" providerName="System.Data.SqlClient" />
    
  4. Replace the entry with the following (substitute your server name, database name, logon, and password where appropriate).



    <add name="ApplicationServices" connectionString="Server=tcp:[your
    server name];Database=[your database name];User ID=[your login name]
    Password=[your password];Trusted_Connection=False;Encrypt=True;"
    providerName="System.Data.SqlClient" />
    
  5. In Solution Explorer, expand the Roles folder underneath the Windows Azure project if it is not already expanded, and double-click Web Role.



    Écran référencé

  6. Select Virtual Network, click the Activate Windows Azure Connect check box, and enter the activation code that you obtained during the final step of the Configuring Windows Azure Connect (pre-Deployment) section.



    Écran référencé



    The ASP.NET Web Role is now configured to connect to the on-premises SQL Server database by using Windows Azure Connect.

Deploying the ASP.NET Application

In order to test the connectivity between the hosted ASP.NET application and the on-premises SQL Server, the ASP.NET application must be deployed to the Windows Azure environment. If you already understand the Windows Azure deployment process, deploy the ASP.NET application to Windows Azure, and proceed to the Configuring Windows Azure Connect (post-Deployment) section.

  1. If necessary restart Visual Studio, and open the Windows Azure project that was created as part of the last section.

  2. In Solution Explorer, right-click the Windows Azure project, and click the Publish option.



    Image référencée

  3. In the Deploy Windows Azure project dialog box, select the Create Service Package Only option button and click OK.



    Image référencée
  4. A Windows Explorer window opens to the location where the application's deployment package and service configuration file were created. Additionally, a browser window should open that directs you to the Windows Azure management portal. If the browser window did not open, start a new browser session and log on to the Windows Azure management portal, which is located at http://manage.windowsazure.com.

  5. Click the Hosted Services, Storage Accounts & CDN option on the toolbar on the left side of the screen.



    Image référencée

  6. Click the Hosted Services folder in the toolbar on the left side of the screen, and select the service to deploy the ASP.NET application to.



    Image référencée

  7. In the New section on the toolbar at the top of the screen, click New Production Deployment or New Staging Deployment.



    Image référencée

  8. In the Create a new Deployment dialog box that appears, enter a deployment name and use the Browse Locally… buttons to select the deployment package and configuration file that was created in step 3. Click OK to start the deployment.



    Image référencée
  9. The deployment can take anywhere from 10 to 15 minutes, or even longer. You can monitor its progress in the Hosted Services window.



    Image référencée

  10. When the deployment is complete and the web role has a status of Ready you can continue to the Configuring Windows Azure Connect (post-Deployment) section.



    Image référencée

Configuring Windows Azure Connect (post-Deployment)

Before the ASP.NET application can connect to the on-premises SQL Server database, there is one additional step to perform. This section will show you how to configure Windows Azure Connect to enable communication between Windows Azure and the on-premises SQL Server.

  1. Log on to the portal, which is located at http://manage.windowsazure.com.

  2. Click the Virtual Network option on the toolbar on the left side of the screen.



    Écran référencé

  3. Expand the Connect folder in the tree view on the left side of the screen. Expand the subscription you configured for Windows Azure Connect, and select Activated Endpoints. You should see the server where the local endpoint was installed, as well as the role instances that host the ASP.NET application.



    Écran référencé

  4. You need to create a Windows Azure Connect group to enable communication between the ASP.NET application and SQL Server. Click the Create Group button in the Configure section of the toolbar at the top of the screen.



    Écran référencé

  5. In the Create a New Endpoint Group dialog box that appears, enter a Group name and a Description.



    Écran référencé

  6. Click the Add… button in the Connect from section of the dialog box to select the server where the Windows Azure Connect local endpoint was installed. Click OK.



    Écran référencé

  7. Click the Add… button in the Connect to section of the dialog box to select the web role that hosts the ASP.NET application. Click OK.



    Écran référencé

  8. Click Create in the Create a New Endpoint Group dialog box to create the group.

  9. To verify that the group was created, click Groups and Roles under the current subscription, in the toolbar on the left side of the screen. The group that was just created should appear. The server where the Windows Azure Connect local endpoint was installed, and the web role that hosts the ASP.NET application should be listed as members.



    Écran référencé

    At this point, the ASP.NET application that is hosted in Windows Azure has been successfully configured to use Windows Azure Connect to communicate with a SQL Server database that runs on-premises. The last thing to do is to test the application to ensure that everything is working as expected.

  10. Log on to the portal, which is located at http://manage.windowsazure.com.

  11. Click the Hosted Services, Storage Accounts & CDN option in the toolbar on the left side of the screen.



    Écran référencé

  12. Click the Hosted Services folder in the toolbar on the left side of the screen, and select the deployment that hosts the ASP.NET application.



    Écran référencé

  13. In the Properties toolbar on the right side of the page, click the link found under the DNS name property. This will direct you to the web site that runs in Windows Azure.



    Écran référencé

  14. Click the Log In link that is on the right side of the page that appears.



    Écran référencé

  15. On the next screen, click the Register link.



    Écran référencé

  16. Fill out the fields on the Create a New Account page that appears, and click the Create User button.



    Écran référencé

  17. If everything works as expected, you will see the user name that you entered on the registration page in the upper-right corner of the page that you are redirected to when registration is complete.



    Écran référencé

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft. Tous droits réservés.