In the first article in this series, "Accessing Enterprise Data from SQL Server CE" [.NETDJ, Vol. 1, issue 6], we constructed a solution that allowed us to provide enterprise data access to mobile devices while in a disconnected environment using Visual Studio .NET 2003, the .NET Compact Framework, and SQL Server CE 2.0. Providing mobile users offline access to their enterprise data, along with the ability to propagate changes back to the server, is a powerful addition to any mobile architecture. But this additional functionality comes with the responsibility of securing your data while "out in the wild."

Whenever you create architectural scenarios in which your data is accessible outside of your infrastructure, you need to make data security a top-priority feature. Mobile data access is no exception. Consider the ramifications of hackers abusing your application's SSCE virtual directory to either deny access to legitimate users or steal critical enterprise data. While the functionality of mobile enterprise data access is a powerful addition to your architecture, it comes with great responsibility. Combining solid code and great features with sound security practices provides your users with a compelling application from both a functional and nonfunctional point of view.

In this article, we'll take the functionality we developed in the first installment and harden the solution to be both functional and secure. We'll secure access to the data on the back-end server by leveraging security features built into Windows Server 2003, SQL Server 2000, and IIS 6.0. We'll secure the transmission of data between device and server to ensure that data is hidden from prying eyes while en route. Finally, we'll modify our code to allow authenticated and secure transfer of data between server and device.

For this article, you'll need to start with the solution offered in our earlier article. (The source code is available at www.sys-con.com/dotnet/sourcec.cfm.) For this solution, we'll use Visual Studio .NET 2003 and the .NET Compact Framework to develop the solution, and SQL Server 2000, IIS 6.0, and Windows 2003 for the server infrastructure. Some of the steps will be slightly different on Windows Server 2000, so check the documentation if you are using that version of the server.

Secure Infrastructure Topology
Our previous solution used some less-than-secure coding and infrastructure practices to get the functional side of things up and running. We leveraged Anonymous authentication when connecting to the SSCE virtual directory via HTTP and we left the data transfer open to prying eyes by sending the data over the wire unencrypted. We used sa/password as our account for accessing the data and passed that account information over the wire as plain text. All of this should leave a modern developer queasy when imagining such practices in production. Let's take a look at a functional and secure way of delivering this functionality.

As we learned in the first article, using SSCE gives you the advantage of using existing infrastructure to create the solution, most notably using IIS 6.0 and Web infrastructure as the means of communication between the device and server, as well as leveraging SQL Server functionality such as replication. It should come as no surprise that we'll be securing our mobile data solution using security concepts that are well known to .NET developers, including IIS authentication/authorization, as well as SQL Server replication security features.

Figure 1 illustrates the topology of our secure solution. We'll authenticate users using IIS and Basic authentication. Once authenticated, we'll use NTFS security to provide authorization to resources such as the virtual directory and the server agent ISAPI DLL. Note: Since we're using Basic authentication with IIS, we'll need to configure our server to use HTTPS/SSL for communications to protect the account information as it moves over the wire. (Basic authentication works for the Internet, but sends authentication information over the wire as clear text.) HTTPS/SSL will also protect the data as it moves between the device and the server. The UI will be modified to prompt for account information and will use that account information for all communications with IIS 6.0, as well as SQL Server.

Securing Your SQL Server Database
We'll start by securing access to our database by allowing only specific users access to the database. Using SQL Server Enterprise Manager and the SimpleSSCEExample database we created last time, create two accounts on your server machine for testing, UserCanAccess and UserCannotAccess. Give each user a strong password. Add both accounts to SQL Server as logins and add the UserCanAccess account to the SimpleSSCEExample as a User with the proper permissions for accessing the database, including inserts, updates, and deletes. At this point, we have one user who can access the database via RDA, and one who cannot. Remember that RDA just passes SQL statements to SQL Server, and does not have any explicit security features itself. If the user is authenticated and has rights to the database he or she can pull and push data between device and server.

On the other hand, replication lets you differentiate users who can access the database and users who can access the publication. We'll restrict access to the Publication and the Publication Articles, so that only specifically authenticated users can transfer data via merge replication. Select the SimpleSSCEExamplePub and open the Properties dialog. Click on the Publication Access List tab, click Add, and select <MyMachineName> \UserCanAccess and click OK. Now only UserCanAccess can access the publication. Next, we'll use the Check Permissions option on the publication articles themselves to further refine who can or cannot merge data with the publication database. Click the Articles tab and click the ellipses button next to each article. While in the Article dialog, click the Merging Changes tab and select INSERT, UPDATE and DELETE. This change forces a check on whether the authenticated user has rights to change data via Insert, Update, and Delete statements. Use this feature to refine which modifications are allowed on each article via replication. This is a great way to differentiate between users who can pull down data for viewing and those who can modify data via replication (and to what level). Click Apply.

Using IIS 6.0 Basic Authentication and SSL
Now that we have the database configured for access to authorized users, we need to configure the virtual directory for authentication. We'll do this without the wizards so we can discuss each step of the process and how it impacts our infrastructure.

Start by opening the SQL Server CE Connectivity MMC and deleting the current SimpleSSCEExampleSynch entry. Also delete the virtual directory folder.

Next, open IIS Manager and create a new virtual directory named SimpleSSCEExampleSynch and map it to a directory on your machine with the same name, such as c:\SimpleSSCEExampleSynch. Copy the SSCE Server Agent DLL, sscesa20.dll, to this location (it can be found on a machine with SSCE server components installed under C:\Program Files\Microsoft SQL Server CE 2.0\Server) and give the virtual directory Execute permissions.

With the virtual directory in place, configure IIS 6.0 so that we can identify who is requesting access to the server agent and then limit execution rights to users of the system. We'll do this using Basic authentication. In IIS Manager, select the SimpleSSCEExampleSynch virtual directory and open the Properties page. Select the Directory Security tab in the Properties dialog and click the Edit button under Authentication and Access Control group. Make sure that only Basic authentication is selected and note the warning about sending authentication information over the wire as clear text. In order to use Basic authentication in a secure manner, we'll need to configure SSL as well to protect the transmission. Utilizing SSL in this manner will also protect the transmission of data between the device and the server agent endpoint.

In order to do this, you'll need to install a server certificate on your server. See the IIS documentation on how to set up SSL with server certificates. Once you have a certificate installed, click Edit under Secure Communications in order to configure SSL. Select Require Secure Channel and Require 128-bit encryption. Click OK until the Properties dialog is dismissed.

Now that we've set up the authentication of our users, we need to enable execution of the sscesa20.dll and enable the proper NTFS permissions for exchanging data. Browse to the directory that is mapped to the SimpleSSCEExampleSych virtual directory in Windows Explorer and right-click on folder to access the Properties dialog. Grant read and write NTFS permissions to the UserCanAccess account for this folder so that intermediate files can be placed in this folder by sscesa20.dll. Open the folder and grant read and execute NTFS permissions to the sscesa20.dll for the same account so this DLL can execute under the authenticated identity of our UserCanAccess account. You'll need to do this for each user, or preferably create a role for the users and add users to that role.

In this example I'm running Windows Server 2003, so I'll need to add sscesa20.dll as a Web extension in IIS 6.0. IIS 6.0 by default will not allow dynamic content, including ISAPI DLLs, to be served until you enable it. Open IIS 6.0, select the Web Service Extensions folder, and click the link for Add a new Web Service Extension. Give the new extension the name SecureSSCESynch and browse to the sscesa20.dll in our virtual directory to designate which DLL is allowed as the Web extension. Also set the Set Extension status to Allowed so the DLL will be allowed to execute out of the gate.

Now that we have the virtual directory covered, we'll further lock down our infrastructure by configuring a specific snapshot folder for intermediate files during replication and restrict access to that folder. Since the sscesa20.dll will run under the account that has been authenticated by IIS, we'll need to provide read access to the snapshot folder for each account that will perform replication. Create a shared folder called SimpleSSCEExample_Snap shot. Give UserCanAccess read access to the folder. Also give full control to the account that the SQL Server Service and SQL Server Agent will run under.

Finally, point the SecureSSCEPub publication to use the SimpleSSCEExample_Snapshot folder. Open Enterprise Manager, open the Properties dialog, uncheck Generate snapshots in the normal snapshot location, check Generate snapshots in the following location, designate \\<MyServerName>\ C$\Sim pleSSCEExample_Snapshot as the new location, and click Apply.

Checking your work at this point is a good idea. Open IE on your development machine and on your device and browse to https://<MyServerName>/SSCEExampleSynch/sscesa20.dll. You should be prompted to enter your account info. Enter the UserCanAccess account and then the UserCannotAccess account to make sure that authorized users have access to the SSCE Server Agent virtual directory. You know you've got the configuration right when UserCanAccess gets the message "SQL Server CE Server Agent" when browsing to the virtual directory directly.

Securing the SSCE Application Code
In this step we'll take a look at the code that's needed to access the secure connection to the server. First, we'll modify the UI to request user name and password. Open the SSCEExample.sln you created in VS.NET 2003 from our previous article and drop the controls described in Table 1 onto the form.

Now let's modify the code step by step, making our mobile application more secure while fixing security faux pas that we made while getting things up and running. First, let's correct the connection string we used as the olddbConnectionString parameter when using RDA to execute SQL statements on our remote server. Compare the connection strings shown in Listing 1 .

The commented-out version is abysmal. It uses SQL Authentication and sa/password (the insecure developer's "dirty little secret" to get things running). The new version is much more secure. It uses the setting "Integrate Security = SSPI", which uses the current authenticated user (running sscesa20.dll in IIS) as the identity to pass to SQL Server. It also uses the setting "Persist Security Info=False", which prevents the account information from being returned in the result of the connection being made. So already we've avoided a password in our code and we're using the authenticated user's account to flow authorization. That's a good start.

Next, we need to change our code to use SSL and provide the account information that we'll use to authenticate our user with IIS and SQL Server 2000. Take a look at the code in Listing 2 to see the changes to our RDA code.

This is straightforward; we just need to point our instance of the SqlCeRemoteDataAccess class to the new URL that is protected via SSL encryption and the account information via the InternetLogin and InternetPassword properties of that class. That's it for RDA. You can run the solution and click on the RDA button to check your work.

To finish up replication, we need to make a few more changes to the code behind the corresponding button and our usage of the SqlCeReplication class. Take a look at the code in Listing 3 .

Again, these simple code changes correspond to our infrastructure changes, including the usage of SSL reflected in the InternetURL property and the inclusion of account information in the InternetLogin and InternetPassword properties. Note: We're getting rid of another security "worst practice" by changing the PublisherSecurityMode setting to SecurityType.NTAuthentication in order to flow the NT account information provided earlier and to avoid the propagation of sa/password usage.

That's the final code change. Run the solution using the UserCanAccess account we've set up and test the exchange of data between the device and server. Also check to make sure that unauthorized accounts cannot access the server data and add some useful exception handling for the exceptions that are raised. If you have issues, take a look at SQL Server CE 2.0 Books Online (Click Here!) for troubleshooting information and recheck your infrastructure settings. Often a single check box setting can make all the difference with security-based code if things don't work out on the first try.

Conclusion
Now we have a solution that is both functional and secure, which is what we set out to do. We've restricted access to our server by requiring that users authenticate when using either RDA or replication. We used encryption via SSL to ensure that both account information and our data is protected as it moves across the wire. We also managed permissions on server resources to grant the least-required permissions to get the solution up and running. From there it was just a matter of some simple code changes.

Now we have the best of both worlds, mobile device access to our enterprise data, as well as the confidence that our data and server can be accessed only by legitimate users. Take this code and integrate it into your infrastructure to add to your solutions the "wow factor" that only mobile development can add.

Please note that the ideas, opinions, and information contained in this article are those of the writers, not of Microsoft Corporation.

About The Authors
Based in the Midwest, Chris Mayo is a Microsoft .NET technology specialist for the developer platform. Chris has over 10 years of experience developing enterprise software as a developer and an architect. His experience dates back to the days of VB 2.0 and includes development on the COM(+), .NET, and J2EE platforms. As a local .NET developer evangelist, Chris speaks at INETA, VS, and .NET user group meetings; the MSDN series; and conferences such as VSLive! and DevDays. cmayo@microsoft.com

Jon Rauschenberger is a partner and the managing director of Clarity Consulting Inc., a Chicago-based, IT consulting firm. In addition to architecting and building scalable Web-based solutions, Jon speaks at conferences such as Microsoft TechoEd, VSLive!, Comdex, and DevDays. Jon is a frequent author of technical articles and white papers and is the MSDN regional director for Chicago. jrausch@claritycon.com

Listing 1: The new and improved connection string

Dim remoteConnString As String = "Provider=sqloledb;
Data Source=MyServerName;
Database=SSCEExample;
Integrated Security=SSPI;
Persist Security Info=False"
'Dim remoteConnString As String = "Provider=sqloledb;
Data Source= MyServerName;
Database=SSCEExample;
User Id=sa;
Password = 2ReplMe!Baby"



Listing 2: Pointing RDA to the SSL connection and providing account information

'///RDA
		'///Where to find the server agent via HTTP
  '///requests.
Rda.InternetUrl =
"https://<MyMachineName>/SSCEExampleSynch/sscesa20.dll"
            Rda.InternetLogin = txtName.Text
            Rda.InternetPassword = txtPassword.Text






Listing 3: Replication code changes

 '///Replication
 '///Set Internet properties for
 '///authentication/authorization with IIS/SQL
        repl.InternetUrl =
		"https://<MyMachineName>/SSCEExampleSynch/sscesa20.dll"
        repl.InternetLogin = txtName.Text
        repl.InternetPassword = txtPassword.Text

'///Set Publisher security properties.
        repl.PublisherSecurityMode =
		SecurityType.NTAuthentication
        'repl.PublisherLogin = "sa"
        'repl.PublisherPassword = "password"