MS Site Server 3.0 Security Components

On This Page

	Definition of Terms
	Chapter 1: Overview
	Chapter 2: Detailed Discussion of Scalability and Performance
	Appendix A: Testing Methodology
	Appendix B: Scaling Summary
	Appendix C: Critical Monitoring Counters
	Appendix D: Authentication Service Transactions

Definition of Terms

Top of page

Chapter 1: Overview

Analyzing Security Components

Microsoft® Site Server 3.0 supports two security modes: Membership Authentication mode and Microsoft® Windows NT® Authentication mode. Each mode has a specific set of identification and authentication methods. The preferred mode depends entirely on the needs of a particular site. Intranet and Internet sites have different security needs, as do Web sites that host large user communities.

The two security modes can be used alone, in combination, or in combination with Microsoft® Windows NT Server's Internet Information Server (IIS) services Anonymous access.

Windows NT Authentication mode supports the following identification and authentication methods:

Membership Authentication mode supports these identification and authentication methods:

Projecting Total Resource Cost

A model is designed in which total resource cost is calculated for a variable number of concurrent users. Essentially:

C = n * K

where C is the resource cost, n is the number of concurrent users, and K is the sum of the costs of each user operation.

Separate equations are created for each type of resource (CPU, memory, disk, and network). Thus, it is possible to predict intelligently the maximum number of users a particular hardware configuration can support, or conversely, the required hardware resources for a given number of users.

Verification Testing

The accuracy of these calculations is confirmed by comparing the results of the calculations with a series of verification tests. A test script is created that simulates a typical user behavior as defined in the user profile. The predicted resource costs calculated from the model are charted against actual resource costs generated by running the verification script.

Note: Your performance numbers may vary from those provided here based on your hardware and software platform.

System Configuration

Processor Scaling

¹ To test the scaling of the authentication service, the number of processors in the Web server was varied at one, two, and four.

Membership Directory Description

Introduction to Security

Whether you choose Membership Authentication mode or Windows NT Authentication mode depends on the sensitivity and value of a site's data, the client software that the site supports, and the expected threats to the site. Choosing between security and performance is a trade off. The less secure methods are generally faster or easier to administer.

In general, transactions are separated into pairs. The first part of the pairing represents the first page request a user makes to a secure page. When this first request is made, the Web server returns an access-denied error to the client and requests user credentials. This is the negotiation phase and is more expensive.

Although the initial transaction includes the negotiation phase, the second transaction contains multiple page requests. Subsequent page requests do not require negotiation. Typically, a Web browser continues to pass credentials to the same Web server for subsequent requests. In these transaction groups nine additional page requests were made.

The Automatic Cookie Authentication scenario is a special case, and is broken down into three parts. In the first scenario, the first time a user visits an Automatic Cookie Authentication- protected site, a new user is created in the Membership Directory, which is quite expensive. The second scenario models a new user who visits the site for the first time and then performs nine more page requests using the new cookie. The third scenario is a user who already has a cookie and performs page requests.

There are no additional objects on any of the Web pages used for the analysis.

Transactions

User Profile

The security user profile is determined by planning a typical Web user visit to an authenticated site. In this example, the typical user visits the site for an average of 10 minutes. During the 10-minute visit, the user will visit five Web pages. All of these Web pages are authenticated. The first 4 pages are secured with Automatic Cookie Authentication. The users already have cookies, so their cookies will not have to be created in the Membership Directory. Their fifth page GET will be secured with Membership Basic Authentication. At this point, the user will have to enter a name and password.

All pages requested have no additional objects.

Web Client

Summary of Scalability and Performance

Based on the data collected in this document, the following assertions can be made about scaling and performance:

Maximum Authentications per Second

See full-sized image.

Security Service Scaling

Every authenticated user adds to the resource overhead of the Web server running the Broker Service. Additionally, if the requested user information is not cached in the broker, then a request is made to the LDAP server, which will in turn request the user information from the SQL Server. NTLM and Windows NT Basic Authentication are not supported in the broker service and its cache.

Top of page

Chapter 2: Detailed Discussion of Scalability and Performance

Processor Usage

The PPEM costs of the transactions for Authentication are not all constants. They vary with the rate of the transaction. When the transaction rate is low, the costs tend to be higher, and likewise, when the transaction rate becomes higher, the costs of some of the transactions rise. Thus, the PPEM is not always a constant; it could be a downward or upward slope. This table represents the least squares approximation of the PPEM versus Transaction Rate curves that were measured in the test environment. The relative accuracy of these measurements is confirmed in the following verification section.

The PPEM at a given rate on a given processor equals C1 + C2r.

Refer to Appendix A for a detailed explanation and example of how PPEM is calculated.

Formulas for Calculating Expected CPU

Four-processor

Two-processor

One-processor

Memory Usage

The following table represents the additional memory overhead associated with running this type of authentication on a Web server that is not running authentication. The calculations are not based on a per-transaction cost, but are based on the cost overhead for running any particular security method. There is an additional cost of 24K per current connection.

The memory cost was determined as follows. The Web service was restarted and the authentication service stopped. The memory usage was measured at this point. Then the authentication service was started and several authentications of the corresponding type were performed. The memory was again measured. The difference between the two measured costs represents the additional memory overhead.

Network Usage

The bitwise network traffic for security should be measured in the number of packages that constitute the overhead. The amount of bit traffic is obviously dependent on the items returned. This table describes the number of protocol roundtrips required to do the different authentications.

SQL Server Usage

The chart below shows SQL Server resource utilization per transaction type. The cached queries do not make any requests to the SQL Server. This chart also assumes that the user information is not in the broker cache. The PPEM for the user password search is low. Furthermore, when the user password is retrieved, all of the user's other data is retrieved, as well, which speeds up subsequent user request information. This chart further assumes a small member object size. If the member size is larger than one SQL Server disk read, then the Read Data operations will be higher.

Resource Usage Calculations

Resource usage calculations are created to answer the question: What is the cost to support a given number of users? Given this information, the next question is: What is the maximum number of users this configuration of resources can support?

In order to determine capacity for each resource, equations can be designed that measure resource cost against number of users.

Profile Calculations

An examination of the user profile needs to occur before looking at specific components of the CPU, disk, and network calculations. Using the number of concurrent users to determine maximum capacity is difficult if user behavior is not taken into consideration.

Multiplying the user profile by the number of users generates this table. For example, 500 users multiplied by the frequency of cookie authentication per second (0.006667) gives 3.33 cookie authentications per second on the server.

The following table is an expansion of this concept by user count and the transactions in the user profile space.

User Profile Frequency

Processor Calculations for Web Server

See full-sized image.

This graph exhibits the scaling behavior of the user profile across multiple processors.

The following tables show the individual data values used to generate the graph.

Four-processor

Two-processor

One-processor

Network Calculations

The number of roundtrips for authentication per user is one each for the first four cookie authentications plus two for the Membership Basic Authenticated page.

This scenario generates a total of six round trips per visit.

Disk Calculations

The following table enumerates the expected disk reads on the SQL Server for the authentications. These numbers are not measured, but are logically determined because SQL Server requires a read from the user directory to retrieve the password information for a user.

One disk read will occur for the group of cookies and one for the Membership Basic Authentication information.

It should be noted however that the Authentication Service reads the entire user object that contains the cookie information as well as the additional password. So, it should not be necessary to make this additional read. However, in this scenario the additional request is performed. This user makes a unique call into the Membership Basic- secure section of the Web site. This call requires a separate read from disk.

Additionally, these disk numbers assume that the index for the members is in the cache. For a worst-case scenario it should perform four reads per user lookup. Although in that scenario the SQL Server computer is severely overloaded and more RAM should be added to increase the caching.

See full-sized image.

Sample Configuration

Site Configuration Example

This example illustrates how to determine an optimal configuration for a given number of users.

200,000 total users

4 percent online at peak time = 8,000 concurrent users

Profile Calculations

Determine the transaction rate T for the individual transactions that make up the user profile.

n x f = T

8000concurrent users * 0.006667frequency for cookie auth = 53.33 = Tcookie

8000concurrent users * .001667frequency for basic auth = 13.33 = T membership basic

Sample Processor Calculations

PPEM = T * cost

2-proc: PPEMcookie = 53.33 * 0.49 = 26.13 PPEM

2-proc: PPEMm. basic = 13.33 * 2.08 = 27.73 PPEM

For a total of 53.86 PPEM which is 13.46 percent CPU utilization on a two-processor computer.

Sample SQL Server Disk Calculations

Disk Reads = T * cost

Disk Readcookie = 13.33 * 1 disk reads/sec

Disk Readm.basic = 13.33 *1 disk reads/sec

For a total of 26.66 SQL Server disk reads per second.

Sample SQL Server Processor Calculations

This calculates the number of accesses necessary to read the user information in order to fill the broker cache. Each lookup operation costs .22 PPEM on the four-processor SQL Server.

SQL PPEMcookie = 13.33cookie lookups * 0.22member lookup cost = 2.93 PPEM

SQL PPEMm. basic = 13.33m. basic lookups * 0.22member lookup cost = 2.93 PPEM

For a total of 5.87 PPEM or .73-percent CPU utilization.

Top of page

Appendix A: Testing Methodology

Calculating the Per Transaction Cost

To calculate the PPEM from observed data, the load was simulated on a per transaction basis. In this case, Automatic Cookie Authentication cached with creation. An automated script was run that cycled through a changing user load. The values were captured in a perfmon.exe log file. This log file was then exported to a tab-delimited text file and imported into Microsoft® Excel. Next, using an Excel macro, the log was distributed and averaged. Each row in the chart below represents several minutes of the transaction load. Many values are captured, too, but these figures are the most important for calculating PPEM.

To establish a valid range of samples, context switches are observed. The context switch rate must be below a certain threshold to be considered running optimally. However, the processor should be exercised across a full range.

This table represents the actual counter objects and values of the system during simulation.

In the next chart, below, total processor time is multiplied by the clock capacity of the system, which in this case is 4 x 200, and then is divided through by the number of authentications per second. Next, the overall PPEM is calculated by taking a polynomial fit using least squares approximation of the PPEM value at the transaction rate. This equation generates the formulas presented in Chapter 1 for each transaction.

See full-sized image.

In this case, the best fitting is a constant value.

Verifying Actual versus Calculated

The user profile was then tested and run in the lab. The site had five Web pages: a.htm through e.htm. The first four were protected with Automatic Cookie Authentication and e.htm was protected with Membership Basic Authentication. The test client computers were running InetMonitor. They used a cookie list file with 96 valid cookies. When the client hit the e.htm page, the client and the broker switched to basic authentication and used the password for the user. The script paused between GET requests to simulate a user reading their information. This script is included in Appendix D.

The following table shows the data that were collected while testing the Web server with four processors enabled.

Five hundred users were run against the system for 10-15 minutes so that stability could be achieved. These PerfMon results were averaged over a 1,000-second period. PerfMon recorded the actual number of authentications of each type per second. In order to calculate expected CPU on this four-proc system, the number of Automatic Cookie Authentications was multiplied by the PPEM value to achieve an overall PPEM calculated for Automatic Cookie Authentication. For example, at 500 users the 32.90auto cookie * 0.56PPEM 4proc auto-cookie = 18.42 PPEM.

This process was repeated for Membership Basic Authentication costs. Then, the CPU % was calculated by adding the 2 PPEM values and dividing through by PPEM of the four-processor system. For example, 18.42PPEM Auto-cookie + 16.85PPEM M.basic = 35.27PPEM Total = 35.27 / (4 x 200) = .044 = 4.4% CPU.

See full-sized image.

This is the two-proc table for the same verification scenario.

See full-sized image.

Top of page

Appendix B: Scaling Summary

This graph shows an approximate comparison of the processor configurations versus the cost for each operation. It is only approximate because it ignores the second term for several PPEM values. It does, however, accurately reflect the relative inefficiency of the four-processor configuration.

See full-sized image.

Top of page

Appendix C: Critical Monitoring Counters

All counters noted can be found in the Windows NT Performance Monitor. These counters will be distributed among the computers in the Personalization and Membership (P&M) service group. The counters in the system and memory objects can be used to monitor capacity.

Site Server LDAP Service

Connection Current

Static Search per second

Site Server Authentication Service

Automatic Cookie Authentication Successes per second

ClearText Authentication successes per second

DPA successes per second

HTML Forms Authentication successes per second

Requests served from cache

SQL Server

SQL Server I/O transactions per second

Physical Disk

ASP Object

Requests/second

Current requests

Web Object

NonAnonymous Users/second

Get requests

System Object

Processor Object

Memory Object

Top of page

Appendix D: Authentication Service Transactions

Set up to verify:

Verification Script

USER tstRANDNUMBER(1,1000) password
GET url:/verify/a.htm
SLEEP 120000
GET url:/verify/b.htm
SLEEP 120000
GET url:/verify/c.htm
SLEEP 120000
GET url:/verify/d.htm
SLEEP 120000
GET url:/verify/e.htm
SLEEP 120000

Top of page