Welcome to the inaugural issue of In the Spotlight! Once each month, I'll "spotlight" a technology and/or technology issue—exploring the features and concerns, if any. I'll cover some of the more interesting and important issues and technologies that developers, architects, and network engineers might face when designing, building, and deploying .NET applications.
One of my clients is a large-enterprise .NET early adopter, one of 50 companies around the world that has committed to putting the .NET platform into action. This team has worked for months on tediously designed specification documents and prototypes. Although I'm bound by a very strict nondisclosure agreement (NDA), I have support from Microsoft to deliver information that is ready for public consumption. And let's face it—anything that I can't say right now will eventually be ready for public consumption.
I've talked to the .NET product team, and the team members are excited that SQL Server Magazine has provided this UPDATE as a vehicle to get the .NET message out. Regularly, I'll get tips and ideas for this column from them.
For instance, here's a recent topic of discussion: Currently, those of us in the software development community who write many Microsoft .NET Server intranet/extranet applications configure the IIS 5.0 Web server as "trusted for delegation." Doing so means that the system forwards the Kerberos ticket that an authenticated Win2K user owns through the Web server to the client using the browser. This model has some security risks because a really smart software engineer with bad intentions, inside the firewall, can "glom on" to a COM+ component running on the Web server under a proxied security privilege. Obviously, this security issue isn't a huge one because the intruder would have to authenticate on the Win2K domain, on the LAN, and inside the firewall to take advantage of this supposed weakness. But that isn't the point—the question is, "How in the world do we ensure a secure authentication in an extranet application in .NET?" The Redmond folks on the .NET team tell me that we simply need to add a line to config.web:
<identity impersonate="true"/>
I should have known that it would be so simple in ASP.NET. We get so much for free in the .NET platform.
A question still exists about how we are going to ensure a secure authentication outside of the firewall without using VPN, public key infrastructure (PKI), or Secure Sockets Layer (SSL)—or some combination of the three—to secure the wire itself. As yet, Simple Object Access Protocol (SOAP) has no security specification. So other than securing the wire, we're still looking at securing at the application level or—Heaven help us—at the protocol level. But that is exactly the type of subject we'll discuss in this column in the upcoming months!
So until next month, keep immersing yourselves in these new technologies and feel free to let me know what issues you'd like to see me cover in this column. Email me at [email protected] or post your thoughts as a Reader Comment.
