We dipped into the Microsoft Developer Network library and came up with this valuable overview of the Windows CE.NET Web Server. Chris Muench of Siemens describes the differences between CE.NET Web Server and the Internet Information Services for Windows 2000 and Windows .NET Server, and discussed how to build, configure, and secure your embedded Web Server.
Introducing the Distributed Ecosystem
Welcome to the distributed world! The role of the Internet has grown as individuals and companies access and share information over a variety of networks. Users demand efficient, standardized interconnectivity to maximize the productivity and entertainment that smarter devices provide. To better suit the needs of this environment, Microsoft Windows CE .NET includes a feature-rich Web Server that offers distributed solutions for these devices.
Introduction
As the IT world changes from "island computing" to "broad distributed computing," tools that enable devices to share information are becoming an essential part of a developer’s resources. The key enablers for the distributed ecosystem are the standards most commonly used by the Internet, such as Transmission Control Protocol/Internet Protocol (TCP/IP), Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML).
Defining the Distributed Ecosystem
Windows CE .NET was created from the ground up to become a first-class citizen in a distributed environment. Although Windows CE .NET was initially developed as a great client, it has matured to fill server needs as well. With the continuing evolution of the Internet toward a distributed network of smart nodes, Windows CE .NET provides a good balance of client and server roles.
Traditionally, a "client" is a defined end-node that receives information from a server, whereas a "server" provides content in response to client requests. In a distributed environment, each node can be a client and server at the same time. A node might request configuration data from a configuration and maintenance server while simultaneously serving its configuration data to other clients that are interested in viewing or changing the data.
In object-oriented programming, you encapsulate specific data for a certain task in a secure location within a class, and you only allow access to it via class methods. These methods are both incoming and outgoing. If you extend the same methodology into a distributed environment, you will conclude that each smart device should encapsulate its data within, and allow access from the outside through standardized methods.
With Web Services, this paradigm finally found a perfect implementation. Web Services allow well-defined and secure access to data across device boundaries, using the Internet as the medium.
The Role of the Web Server
The most important part of a "distributed ecosystem-enabled" device is the Web Server. It handles all incoming requests from other clients and provides a secure and predictable communication interface between your valuable data and the outside world. A Web Server, by design, is able to manage multiple incoming requests simultaneously, guaranteeing the scalability and availability of the server.
Before the Internet, communications across machine boundaries were awkward and complicated. Many protocol negotiations were required, which often led to communication failures. When you use Web Services through a Web Server, all you need to know to start communicating is the IP address of the computer you want to talk to.
How Does .NET Fit In?
Microsoft is introducing the .NET Compact Framework as a new, versatile technology for developing distributed applications. Version 1 of the .NET Compact Framework is intended to allow smart clients to consume Web Services from other devices. Because Web Services do not require the development of any proprietary technology or tools, Windows CE .NET-based devices can serve Web Services like any other smart device. Windows CE .NET includes both the Simple Object Access Protocol (SOAP) client and server parts for building your own Web Services.
The Embedded Web Server of Windows CE .NET
Starting with version 3.0, Windows CE has shipped all the required components of a Web Server. Each version of Windows CE .NET has extended the features and functionality of the embedded Web Server.
The Components of the Embedded Web Server
The embedded Web Server has the following two general requirements:
TCP/IP
You need TCP/IP and a Network Interface Card (NIC) installed on the device that will run the embedded Web Server.
70 kilobytes (KB) of read-only memory (ROM)
The embedded Web Server requires approximately 70 KB of ROM. If you include the Microsoft Active Server Pages .NET (ASP) engine, you need an additional 45 KB of ROM.
The Platform Builder components
The following table shows all Windows CE .NET components of the embedded Web Server. The real size of the components is dependent on the central processing unit (CPU) that the target device is using, and is subject to change in future releases.
What's New in Windows CE .NET
The following features are new in Windows CE .NET version 4.0:
Server-side Secure Socket Layer (SSL) support
Script mapping support
The following features are new in Windows CE .NET version 4.1:
Authentication based on SSL client certificates
Support for IP version 6
Host header support
How To Build a Device That Includes the Web Server
Creating a Windows CE .NET image that includes the embedded Web Server is not difficult. You can follow this procedure to get started:
Start Platform Builder and select File/New Platform . . . The New Platform Wizard appears.
Select Emulator X86 or any other board support package (BSP) you have the hardware for, and then click Next.
The next page asks you if you want to start with one of many predefined platforms. Because all platforms are capable of running the Web Server, it does not really matter which one you choose. Choose the Web Pad as your starting base, and name the platform MyWebPad.
The next wizard page asks you to choose a base template for the Web Pad. Select Enterprise Web Pad with Applications.
The next page allows you to customize some basic features. You do not need to make any changes here. Click Next.
On the next page, open the branch for LAN and select the Wired Local Network, because we want to access the server via our local area network (LAN).
The last page asks if you want to include several other technologies that might be possible security risks. For our example, we do not need any of these technologies. Click Finish.
After Platform Builder has created the platform, in the Component Catalog, open the branch Core OS/Communication Services and Networking/Server.
Right-click the Web Server (HTTPD) component and add it to your platform. Then, confirm the security notification that an improperly configured Web Server can lead to security vulnerabilities.
Add some registry keys and at least one Hypertext Markup Language (HTML) file to the platform.
Set the default page to Default.asp, and add this page into the project to be put into the windows\www directory. You can create the file with the following content:
<% Response.Write("
Hello World
") Response.Write("The Time is "& Now()) %>
Build the platform and launch it in the emulator.
Open Internet Explorer in the emulator and point the URL to http://localhost to see your new page.
Comparing IIS for Windows CE .NET with IIS 5.0/6.0 in Windows 2000/.NET Server
The following table presents an overview of what you can expect from the Web Server in Windows CE .NET compared to IIS on Windows 2000. If you are familiar with the IIS server for the desktop, you will find this section helpful in highlighting differences between the two.
Developing for the Embedded Web Server
Developing ASP Pages for IIS on Windows CE .NET
One of the greatest features of the embedded Web Server is the support for ASP. This allows you to create sophisticated, dynamic pages that, for example, could configure your device or allow you to monitor its current state.
Limitations of ASP for the embedded Web Server
As with all technologies of Windows CE .NET, ASP for the embedded Web Server contains a subset of the functionality that is available in ASP for IIS 5.0.
No state maintained between requests
This is the greatest difference between the IIS and Windows CE .NET implementations of ASP. Windows CE .NET does not provide support for the Session or Application objects and does not send the Session-ID cookie that is used on IIS. Therefore, there is no automatic technique for maintaining state between requests or sessions.
The script writer must maintain information between requests and sessions, and can do this by sending cookies to the client browser. This scheme assumes that the client browser has cookie support enabled.
No
Windows CE .NET–based ASP treats the
Debugging
Although ASP for the embedded Web Server does not support debugging, you can use Response.Write() statements to "debug" ASP pages. Also, because the source code for the Web Server is available for debugging purposes, you can step through the processing of the request in a debugger to help find bugs in ASP scripts.
Securing the IIS for Windows CE .NET
Security is a very important aspect of computing in a distributed and relatively open environment like the Internet. You can manage which users get access to what data on your device. The embedded Web Server supports the following authentication schemes:
No authentication Allows all clients to access the server.
Basic authentication Authenticates users against a user list that is defined in the registry. All users must use the same password, which is set in the Network control panel.
NTLM authentication Uses the same user list as basic authentication, but the Web Server passes the authentication request to a domain controller that is specified in the registry.
SSL Client Certificates Request a certain SSL certificate from the client to log the user on. To learn how the certificates can be set up, please refer to the article on SSL Client Authentication.
The user list
As mentioned above, embedded Web Server security can be managed through a user list. The user list is a registry entry corresponding to each of the virtual roots. For example, you can create a virtual root named "/www".
The first entry "(default)" points to the physical location of your Web pages, in this case in the directory "www" under "Windows".
The second parameter defines what security will be used by the v-root.
A=0—No authentication
A=1—V-ROOT requires a user name and password
A=2—Same as 1 just with additional administrative rights for the user
The third parameter is the user list. You can use the following wildcards:
"-…" denies access to this user
"@.." allow access to this group of users. The group has to match a user group in the domain that will be used to authenticate the users.
"-*" deny all (domain) users
"@*" allows all (domain) users
If you are using basic authentication, the groups wildcard does not do anything. Also, as mentioned above, the incoming authentication request will be verified directly against the user list and the password that is set in the Network control panel of your device. To set basic authentication, use the following registry key:
[HKEY_LOCAL_MACHINE\Comm\HTTPD] "Basic"=1
To enable NTLM (Domain) authentication, you must set the following registry key:
[HKEY_LOCAL_MACHINE\Comm\HTTPD] "NTLM"=1
Locate the users.hts for the userthe root.through a user list. Best practices
Limit deployment to ten connections simultaneously
A typical deployment uses a Web Server in a private network to provide a remote user interface to configure a headless device. The registry defines the number of connections and when the MaxConnections registry value is not set, the registry limits the number to 10.
Do not use the Web Server to perform critical operations
A typical deployment uses the Web Server to display status information or to host a family or community Web site. You should not use the Web Server to perform critical operations, such as machine control or financial processing.
Use authentication
Use NTLM and/or Basic authentication mechanisms to limit access to known users only. You can set the option in the HKEY_LOCAL_MACHINE\COMM\HTTPD registry key. For specific security information, see the "Security Note" in "Base Registry Settings." For more information about authentication, see "Web Server Authentication and Permissions" in the Windows CE .NET documentation.
Use Secure Sockets Layer (SSL)
SSL protocol protects data from packet sniffing by anyone with physical access to the network. For more information, see "SSL Support" in the Windows CE. NET documentation.
Use user access lists
Carefully choose your virtual roots and limit access to the appropriate files by providing appropriate user access lists. Anonymous users with access to the virtual root may be able to access files and directories within that virtual root. You can set the options in the HKEY_LOCAL_MACHINE\Comm\HTTPD\VROOTS registry key. For specific security information, see the "Security Note" in "Virtual Path Settings." Also see "Web Server Authentication and Permissions" in the Windows CE. NET documentation.
Remove or disable sample Internet Server APIs (ISAPIs) and other development tools when you create the retail image
Some sample ISAPIs that you include in your device may allow unauthorized users to access your system resources or protected data. Many of the samples provided are for development and debugging purposes only and pose a significant security risk if deployed on a public network.
Internet Explorer, the Universal Client
As it is on the desktop, Internet Explorer (IE) is the best option for Web navigation on the device. Windows CE .NET comes with two versions of IE: Pocket Internet Explorer (PIE) and Generic Internet Explorer (GENIE).
Pocket Internet Explorer
PIE is a very basic Web browser. It supports basic Web browsing and is optimized for small device footprints.
Generic Internet Explorer
Genie 4.0 (which came with Windows CE .NET 4.0) is based on desktop IE 4.0. It supports many more features than PIE, such as cascading stylesheets (CSS), Dynamic Hypertext Markup Language (DHTML), and scripting.
CEIE 5.5
The latest edition of GENIE is based on IE 5.5 and provides the most comprehensive support of Web features.
Comparing the Internet Explorers
The following table presents a detailed comparison of the different IE versions.
Summary
The distributed ecosystem is continually maturing toward more Web-enabled scenarios. Participating in these environments is becoming mandatory, even for embedded devices. The embedded Web Server is essential to enable a device for the distributed ecosystem. Therefore, you should include it on all devices running Windows CE .NET, even if they are mobile, headless or running in mission-critical environments.
Copyright (c) 2002 Microsoft Corporation. All rights reserved. Reproduced by WindowsForDevices.com under license.
Visual Basic 6.0 to .NET Migration
This paper focuses on the methodology and techniques which Infosys (Microsoft Technology Center) has developed for migrating VB 6.0 Applications to .NET. Our approach ensures a smooth, cost effective, and efficient migration.
Mobile Device Security: The Eight Areas of Risk
It's common knowledge that adding mobile devices to your network increases security risks. There are multiple facets to mobile security, all of which should be paid close attention to. This E-Guide presents a more in depth look into the eight key areas of securing wireless devices.
Quality Assurance and .NET
This paper discusses best practices for functional, regression and load testing of .NET applications.
SCADA Security in Integrated Networks
As businesses leverage their SCADA systems by integrating them into the business networks, they must also assure the security of the SCADA system.
The Advantages of Small Form Factor HMI
HMIs have mutated and changed with new requirements, and they have become more flexible and capable. And while they've been doing that, they've become smaller and more useful.
9 Critical Requirements for Web Application Security
Learn why your Web applications expose dangerous security breaches and what’s required to effectively protect your Web applications and the sensitive information behind them.