Working with multi-tier applications it always has been important to know under which account specific services are running. Probably the most common approach is to let clients running the User Interface connect to a service that on its term connects to the database. To protect against unauthorized access of data only the privileged account that the service is running under is permitted to connect to the database.

That said let’s take a look at Web Services and ask the question: What is the effect of authentication and impersonation settings within Internet Information Server?

Anonymous web services run under the account of the web site and have no further knowledge of the identity of the caller. You will see that the System.Security.Principal.WindowsIdentity is set to the account defined in IIS. That is by default a local account IUSR_>machinename<. All threads spawned to handle incoming web service requests have the same principal, having the same 'anonymous' identity. This can be checked looking at the System.Threading.Thread.CurrentPrincipal.Identity property.

Once you clear the 'anonymous' flag the caller will be requested to provide its credentials. Within the client proxy code you will find code like this: Interesting is to observe what happens on the Web Service side: the WindowsIdentity remains the IIS account, but the ‘thread identity’ is set to the account under which the client runs. It is the thread’s principal, not the WindowsIdentity of the process, that is used to apply the dotNet authorization for methods using the System.Security.Permissions.PrincipalPermission attribute.

Setting the impersonation flag to true causes IIS for a much heavier operation. It now will set the WindowsIdentity of the thread based on the client’s credentials. Consequently threads will run under different WindowsIdentities for different users, such that for example connection pools cannot be used. As authorization just needs the ‘thread identity’ based on a principle it is mainly due to the performance consequences that impersonation is depreciated. Note that for security reasons one can only impersonate using a ‘token’. This token is either retrieved by logging onto the system (using username and password), or by a secure 'channel'. Such a channel is provided with HTTP using "Integrated Windows Authorization".

What does this mean for the scenario given above? If you use a Web Service to communicate between client and server and clear the anonymous option, the thread’s principal that is instantiated which is sufficient to secure the services offered as outlined above. And throughout the service is the identity of the caller known, e.g. to keep track of who modified the database content. This similarly holds if you use dotNet remoting.

But how does this come into play if you use the Web Service from within your server application? In that case the identity passed is based on the server application’s identity. It are its credentials that are used for authentication of the Web Service. The ‘thread identity’ on the Web Service is thus the account the server process uses, not the user’s account of the request. The real user identity is not passed, if one would like to forward it, it needs to be done in a custom manner, for example setting additional custom SOAP headers. I believe that this is from a security point of view no problem. The Web Service is called on behalf of the privileged service, it’s an extension of that service. If the user is not allowed for the Web Service operation the service should guard this. In fact, you may not even wish that the Web Service takes the users identity into account to exclude specific data, e.g. as the data is aggregated before it is sent to the user. But what remains to be a challenge is tracking. With the users identity gone yet another piece of information to relate calls over process boundaries is gone.

Impersonation in the server process would allow for the Web Service called by that server process to know about the user’s identity. Note, this is clearly not recommended and requires additional configuration to allow for what is called delegation. And if you use dotNet remoting between client and server you will notice that impersonation of the remoting service is not supported. That is as dotNet 1.1 remoting does not support a secure channel to transfer the necessary user token.

One other aspect of identity is of interest to be shared. As outlined above, Web Services will run by default under the local account IUSR_<machinename>. If you are accessing a database as third tier, this can cause you some problems. Generally this account will have no rights to access any data from your database. Of course, you could grant permissions to the NT_AUTHORITY\NETWORK SERVICE account, but that will only work for you as a developer. Once the database is placed onto a separate machine you are in trouble with the local account. Therefore configure for your application a dedicated application pool within IIS that is using a domain account. This also allows for a much easier load balancing configuration once you want to spawn your Web Service over multiple servers.

A lot more background information can be found for example in http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetch10.asp. All I want you to take with you is that impersonation in most cases in not necessary. It is depreciated because of its impact for scalability and the larger administration efforts. And Web Services that access a database should be running in a dedicated application pool that uses a domain account.

How often are you referencing to a date in your software? I often have seen that functionally dates are desired, even if they are implemented through a DateTime. One reason could be the extra accuracy the programmer thinks to provide. In that case he will use for example the .Date property in the display to comply with the functional need. But maybe the reason is even more trivial, as there is not a specific data type that excludes hours, minutes and seconds. Dates are stored in C# in variables of type DateTime. In today’s world of gigabytes of storage the extra bits for the time value can be neglected – it are the functional complications that showed for example when using dates in a web service, that cause me to write this article.

Using DateTimes the regular XML serialization will include hours, minutes and seconds. If date variables are initialized properly using the Date property, these fields are zeros. Interestingly in .NET 1.1 the dateTime values are considered to be in the local time zone. Therefore the serialization includes the current time zone as an offset. For example my birthday June 8, 1961 will be:

If this value is received on a system that resides in a different time zone, deserialization will use the offset to adapt the passed datetime value to the local time zone. Consequently it is possible that the date shifts by one day. The timestamp above read in the U.K. (time zone UTC or during summer UTC+1) will result into the 7th of june 10 or 11 o’clock in the evening. Stripped to a date I now have become a day older just by reading my birthday in the U.K. I really disagree getting that easy older (of course, it works the other way round too, taking me to more exotic places).

Even more so, if a uninitialized datetime is serialized the it will be passed being DateTime a value type as DateTime.MinValue, which is January 1st of the year 1. Deserialization in a different time zone will not reveal an uninitialized datetime anymore as the offset is corrected.

The solution to this problem is simple – don’t pass dates as XML datetimes but as XML dates. Dates are not dependent on time zones and therefore no correction is been applied. This can be simply enforced placing an extra XmlElement attribute. This attribute allows us to continue using the C# native datetime type:

Note that serialization of a DateTime property in .NET 2.0 is free of the timezone. It therefore leads to: As you can see this is not consistent, making the use of the XmlElement attribute to restrict the DateTime to just a date in XML all the more desirable.

In 2002 I did co-author one of the primary resources on SharePoint Portal Server 2001. We received some great reviews from the public.

Special Edition Using Microsoft® SharePoint Portal Server Robert Ferguson [et al.] Published August 2002 by Que Copyright 2003, 704 pp., Paper ISBN: 0-7897-2570-3 Back cover Excerpt Full index See all 85 sample pages.

When working for Compaq I have written some articles on SharePoint Portal Server 2001 and the underlying Web Storage System, the engine that also powers Microsoft exchange. If you are still working with these technologies, you may wish to take a look.

Migrating Notes Applications to Exchange and SharePoint Portal Server: Case Study

Powerful Information retrieval with WebDAV and XSL

Searching with SharePoint Portal Server

Build a Web Storage System Solution