The first version of the .NET Framework exposed Web services as an alternative to .NET Remoting. This was an experiment with open standards such as XML, HTTP, and SOAP. .NET Web services were widely embraced by the developers that recognized their value (please refer to my previous articles). Version 1.1 of the .NET Framework focused on the optimization of the Web service execution mechanism. However, large chunks of architecture were still missing. The most important factor was security. OASIS (the standard body responsible for Web services standards) released WS-Security and other WS standards to enhance Web services implementations. Microsoft's implementation of these standards was known as the Web Services Enhancements (WSE).
The first version of the WSE discussed WS-Security, WS-Routing (and WS-Referral), DIME and WS-Attachments and mainly addressed security concerns. The security options for Web services did not extend to the wide requirements of the IT industry. There were limited choices for security on Web services, and they were closely tied to the Windows operating system. (These methods are discussed in Web Services Security in The .NET Framework by Ahmed Siddiqui.)
WSE 2.0 contains the next set of standards released by OASIS. It also includes some of the emerging standards. WS-Addressing and WS-Secure Conversation are a couple of them. Microsoft has also revisited the security architecture of Web services in WSE 2.0, including Kerberos support. This is a huge leap forward for Windows-based code to extend to Service Oriented Architecture. WSE 2.0 was recently released at Tech Ed 2004 in San Diego, CA and is available here.
This article only concentrates on Kerberos authentication. It does not discuss the semantics of Kerberos version 5 (RFC 1510) (please have a look at the URLs defined in the "references" section). However, it is beneficial to discuss the other authentication mechanisms available in WSE 2.0 (please refer to the WSE 2.0 documentation for detailed explanations).
X.509 Certificate: X.509 certificates can be used to authenticate users. The WSE 2.0 has the plumbing to transport the certificate information from one destination to another over SOAP. User Name and Password: The traditional user name password over SOAP can be used to authenticate. However, this is done in plain text. Therefore, SSL / HTTPS need to be utilized to protect the credentials. Custom Security Token: Users can also generate custom binary tokens using WSE 2.0. These custom tokens will not reflect open standards in most cases. Therefore the security architecture may not be extensible to interact with external business partners in a B2B implementations.
Note: All these methods will manipulate the "header" of the SOAP envelope by inserting the token information. The size of the token will depend on the exact method use. (i.e.: A Kerberos token size will be greater than a username password token).
Why Kerberos Authentication?
All of the security mechanisms in WSE are designed for enterprise users. However, building custom token will limit the extensibility of the architecture. The custom tokens are 'customized' for an organization or a business activity. They are not built with open standards. You can facilitate custom tokens within the organization; however, integrating with business partners may cause some headaches.
An enterprise will have multiple authentication mechanisms. Don't be surprised to use a different password for your inventory systems and a different password for your accounting system. A lot of technologies have tried to bridge this gap of "Single sign-on" to eradicate this issue. You need to look closely at the nucleus of this issue. What is the limitation that stops you from using one authentication mechanism?
Windows uses Kerberos tokens to authenticate users. Kerberos can also populate the user group information for a given Windows users; therefore, if you use the native Windows authentication mechanism, you should be able to support any application that runs on the Windows platform. The Kerberos token is already generated at logon. The application requests the token from the domain controller and is reused with other applications. In the previous example the inventory application will get the Kerberos token from the domain controller and share it with the accounting application; therefore, a separate logon is not necessary. You can also reuse the native Windows user groups and privileges in the accounting and inventory applications; therefore, Kerberos authentication is a step closer to having "single sign on" for an enterprise. Kerberos authentication is also more secure than the username password authentication methods.
Now you'll learn how to implement Kerberos authentication with WSE 2.0. You will create a sample application to illustrate this. I have tried to mimic the best practices and the popular architecture designs to make the example as realistic as possible (please feel free to change the structure of the source code. I have not spent much time on comments and structure. The main objective is to illustrate Kerberos authentication with WSE 2.0).
In the second article of his series on Indigo web services, Chris Peiris explains how to host an Indigo web service and examines the IIS, self hosting, and Windows Activation Service hosting options. He then provides step-by-step instructions and sample code for an IIS-hosted and self-hosted Indigo web service. [Read This Article][Top]
In the first part of his series on Microsoft Indigo, Chris Peiris examines the basics of SOA, explains how Indigo fits into the picture and the problems it solves. He then introduces Indigo's programming model and finishes by building a sample Indigo web service using the Microsoft .Net Framework 2.0. [Read This Article][Top]
Adnan Masood concludes his discussion of Microsoft SQL Server Analysis services and Microsoft SQL Server Reporting services. In the final part, he discusses Reporting Server web services and using custom code in reports. [Read This Article][Top]
This article explains the features of the IE Web service behavior and shows how to asynchronously communicate with an ASP.NET Web service directly from the client. [Read This Article][Top]
Calvin Luttrell shows how to validate e-mail addresses stored in Excel 2003 and
provides a special function for solving that pesky problem Yahoo! mail servers cause. [Read This Article][Top]
This short article describes a quick and easy way to provide some security to an ASP.NET Web service by modifying its associated documentation file. [Read This Article][Top]
Chip Irek examines the architectural issues and component design issues of building a .NET application in a service-oriented architecture. [Read This Article][Top]
Thiru Thangarathinam shows how to use asynchronous Web services, Windows
Service applications, server-based timer components and .NET XML API classes to create high-performance, scalable, and flexible applications. [Read This Article][Top]
Part one showed how to transform XML data into HTML by using an XSL stylesheet from within a .NET application. This part explains how to make use of XSLT Extension objects and invoke a C# class method from an XSL stylesheet. [Read This Article][Top]
Learn how to transform XML data into HTML by using an XSL stylesheet from within a .NET application, and then implement a paging solution by declaring and supplying paging parameters to the stylesheet. [Read This Article][Top]
Mailing List Want to receive email when the next article is published? Just Click Here to sign up.
