Here is my usual post-conference post with updated code samples related to the topics I presented on. I did 2 full day tutorials, and 4 sessions...enjoy!

Many of the demos come from my book, Learning WCF. Since there is setup required for most of the samples that illustrate security or rely on a database, it is best you download the entire package of samples and follow the setup instructions provided in the appendix. Here's the link: http://www.thatindigogirl.com/LearningWCFCode.aspx

TUTORIAL: Improve Your SOA: Designing a Secure, Reliable and Scalable System with WCF

• Samples from my book (see above) illustrate exception handling, MTOM, streaming, MSMQ, pub-sub, transactions, security for intranet/Internet/mutual certificate/claims-based/federated, multithreading, and throttling
• Get my latest routing samples here: http://www.dasblonde.net/downloads/Routers.zip
• Additional error handler code here: http://www.dasblonde.net/downloads/ErrorHandlers.zip
• I have additional samples related to proxies here, including a proxy wrapper to address timeouts and uncaught exceptions that fault the channel: http://www.dasblonde.net/downloads/Proxies.zip
• The chunking channel is in the SDK extensibility samples.

TUTORIAL: .NET Roadmap

• The following link has instructions for machine setup used for the demos, and numerous references to resources, and code samples demonstrated: http://www.dasblonde.net/downloads/TechnologyRoadmap0308.zip

SESSION: ADFS and ASP.NET: Supporting Single Sign-On in your Web Applications

• The code I demonstrated in this session is based on the Tech Net tutorial for setting up VPCs for WIndows Server 2008 and ADFS.here: http://technet2.microsoft.com/windowsserver2008/en/library/87e1a178-4d8a-4e89-98b0-d125f9c84c221033.mspx?mfr=true
• As it is published today, the lab has just a few issues that can get in the way of your success with the setup. The following blog post summarizes those issues if you have comments, but I also have a PDF that has a few screenshots here:  http://www.dasblonde.net/downloads/ADFSServer2008LabErrata.pdf

SESSION: Building a Router for your Applications

• I wrote two MSDN articles on this subject, the first is already published here: http://msdn2.microsoft.com/en-us/magazine/cc500646.aspx
• Get the routing samples for both parts here: http://www.dasblonde.net/downloads/Routers.zip
• The second part should be up within another month.

SESSION: Going Federated with WCF

• Most of the samples for this session come from my book code (see above). 
• An additional sample: http://www.dasblonde.net/downloads/SecurityTokenClaims.zip

SESSION: Load Balancing Considerations for WCF

• Samples for this instancing and throttling come from my book (see above).
• I have additional samples related to proxies here, including a proxy wrapper to address timeouts and uncaught exceptions that fault the channel: http://www.dasblonde.net/downloads/Proxies.zip

I recently spent a painful 30-40 hours setting up VPCs according to the Tech Net lab "Step-By-Step Guide for AD FS in Windows Server 2008. The lab is located online here: http://technet2.microsoft.com/windowsserver2008/en/library/87e1a178-4d8a-4e89-98b0-d125f9c84c221033.mspx?mfr=true

In fact, the process didn't have to be so painful except that there are just a few instructions that are less than clear, incomplete or incorrect. Of course, when things don't work as expected I automatically assume that I missed a step, executed a step incorrectly, or just plain didn't know something that the lab instructions assumed everyone knows. So, my natural instinct was to repeat the steps, which I did several times spending many hours since there are 4 VPCs and lengthy installation steps involved for each. As it turns out, just a few fixes to the lab instructions could have avoided all that.

A document summarizing the issues can be downloaded from here, with additional screenshots beyond what is discuss below: http://www.dasblonde.net/downloads/ADFSServer2008LabErrata.pdf.

I hope you find this helpful if you are trying to follow the lab. If you encounter different problems, please do let me know so I can post updates here.

Step 1: Preinstallation Tasks

• Section: Configure computer operating systems and network settings
  • Before you get started, make sure to turn off the firewall settings on all VPCs. The firewall gets in the way of DNS resolution between machines which causes problems with adding computers/users to domains, problems browsing to sites later on in the lab, and similar problems with redirections that take place when you run the lab.
  • During network setup, you don’t need to select server roles yet even though the chart lists them. Just set up the IP addresses at this time. The table listing is just a little misleading as it might lead you to think you need to set up the web server, federation server or domain controller at this point, but there are separate steps for this later.
  • Set IP addresses according to the table for IPv4 and disable IPv6. If you don’t disable IPV6, the AD DS setup will try to enable dynamic DNS and then your static IPs will be blown away.
• Section: Install and configure AD DS
  • The firewall on the adfsaccount machine must be off for this to work.
  • After installing AD DS, check your network IP settings again just to make sure the DNS settings are as you set them in the previous step. I found that sometimes the preferred DNS settings were reset.

Step 2: Installing AD FS Role Services and Configuring Certificates

• Section: Configure IIS to require SSL on both federation servers
  • You can skip this step completely!!!! After you install AD FS there is a new web application directory created under /adfs. The /ls subdir is already set up to require SSL and Ignore certificates. The /fs subdir is already set up to require SSL and Accept certificates. You don’t need to do anything more here. In fact, if you execute this step and set up the default web site to Accept certificates you’ll be prompted to supply a client certificate when you browse to the claims-aware application later on. This will not only confuse you, but prevent you from browsing to the claims-aware application successfully.
• Section: Export the adfsresource server authentication certificate to a file
  • There is no reason that you have to export the private key (.pfx) here. To establish trust only the public key cert (.cer) is required. Following the lab steps won’t hurt you here, but it is important to understand that exporting private keys is not traditionally recommended outside of the machine, domain or application that owns the key.
  • This also implies that the next section could import a .cer instead of a .pfx, depending which route you take.

Step 3: Configuring the Web Server

• Section: Configure IIS on the Web server
  • After completing step #7 to require SSL for the default web site, skip step #8. Leave the setting as require SSL and Ignore client certificates. You don’t want to Accept client certificates, this causes the browser to prompt for a certificate when you browse to the claims-aware application.
  • In fact, step #7 could be modified so that you don’t require SSL for the entire Default Web Site. Instead, you could just require SSL for the /claims-aware application directory which we will be browsing to.
• Section: Create and configure the claims-aware application
  • These instructions are fine, but the files from the Appendix A are incorrect for IIS 7. See my notes on this later on.

Step 4: Configuring the Federation Servers

• These steps are fine, but after you have completed these steps you’ll have to do a few more certificate installations to ensure self-signed certificates are trusted on appropriate machines. I have provided instructions on that below.

Running the AD FS Diagnostic Tool

• When I was trouble-shooting my own lab issues, Joe Kaplan pointed me to the AD FS Diagnostic Tool which is blogged about here: http://blogs.technet.com/adfs/archive/2007/11/01/adfs-diagnostic-tool.aspx. This really helped me to verify certificates were trusted, and that my AD FS configuration was ok. Run this tool and follow the instructions on the blog post. Note the following:
• You will get warnings on the resource server related to E-mail claims, but those do not cause any concern, just ignore it.
• If you do get any errors, fix the problems indicated in the error. I only encountered one or two errors related to self-signed certificate trust, which I explain how to fix in the next section.

Additional Configuration for Self-Signed Certificates

• Since you are using self-signed certs on all machines, it is best practice to install your public key certs into the Trusted Root Certification Authorities store on the machine that owns the cert, and on any machine that must trust the cert. Some of the lab steps address this, but there are a few missing steps and again this can confuse you if you aren’t familiar with certificate issues.
• The following instructions guide you first through exporting the certificates we need to work with. You may have already exported these certs in previous steps, and hopefully are using the same naming convention specified in the lab.

Exporting certificates, if you haven’t already:

• Machine: adfsaccount
  • The private key created for IIS is installed in the Local Machine/My store, called adfsaccount.adatum.com. Export the public key certificate (.cer) if you haven’t already and call it adfsaccount.cer.
  • The private key created for the federation server to sign tokens is installed in the Local Machine/My store, called Federation Server adfsaccount. Export the public key certificate (.cer) if you haven’t already and call it adfsaccount_ts.cer.
• Machine: adfsresource
  • The private key created for IIS is installed in the Local Machine/My store, called adfsresource.treyresearch.net. Export the public key certificate (.cer) if you haven’t already and call it adfsresource.cer.
  • The private key created for the federation server to sign tokens is installed in the Local Machine/My store, called Federation Server adfsresource. Export the public key certificate (.cer) if you haven’t already and call it adfsresource_ts.cer.
• Machine: adfsweb
  • The private key created for IIS is installed in the Local Machine/My store, called adfsweb.treyresearch.net. Export the public key certificate (.cer) if you haven’t already and call it adfsweb.cer.

Importing certificates, if you haven’t already:

• Machine: adfsaccount
  • Import both adfsaccount.cer and adfsaccount_ts.cer into the Local Machine/Trusted Root Certification Authorities store.
• Machine: adfsresource
  • Import adfsresource.cer, adfsresource_ts.cer and adfsaccount.cer into the Local Machine/Trusted Root Certification Authorities store.
• Machine: adfsweb
  • Import adfsweb.cer into the Local Machine/Trusted Root Certification Authorities store.
• Machine: adfsclient
  • In Step 5 you will be asked to install certificates through the browser. This should work just fine for you, thus no need to manually install to the certificate store. In the event you have issues, or if your client is not Vista o XP, you may need to manually install the certificates to trust the downstream services.
  • Import adfsaccount.cer, adfsresource.cer and adfsweb.cer into the Local Machine/Trusted Root Certification Authorities store. This tells IE that the web sites can be trusted even though the certificates are self-signed.

Step 5: Accessing the Sample Application from the Client Computer

• This is the section where I began to have issues, which of course led me to retracing my steps several times unnecessarily as it turned out since the problems were related to a few missing or incorrect steps.
• DNS Resolution:
  • The first problem I encountered was DNS resolution to adfsaccount. I consulted my friend Stephen Rose for this one, and we literally spend hours reviewing each VPC and its IP and DSN configuration, looking for issues. I learned a lot about DNS in the process (Stephen is the man) but we still ultimately had problems pinging one of the machines. As it turned out, the issue was the firewall was still on for one of the machines. Somehow we failed to see that.
  • Make sure you can ping each machine from the adfsclient machine using not just IP address, but actual DNS – check your firewall settings first if you can’t, then check your IP/DNS settings on each machine to match Step 1:
    • Ping adfsaccount.adatum.com
    • Ping adfsresource.treyresearch.net
    • Ping adfsweb.treyresearch.net
  • If DNS is working, you shouldn’t have any issues with the steps in this section of the lab.
• Requiring a Client Certificate:
  • The second issue I encountered was the client certificate issue. When I browsed to the claims-aware application, IE kept prompting me for a certificate with an empty dialog since I had no certificates. I consulted my friend Joe Kaplan for this, thinking I was missing something in my configuration. We extensively reviewed my setup, and in the process stumbled on the IE settings for Accept certificates. He educated me that the adfs/ls and /adfs/fs directories were already set up properly when you install AD FS on the machines…so I rolled back the step that incorrectly configured each web site for the Accept setting.
  • If you skipped the step to configure the web sites to require SSL and Accept certificates, you should be able to get through the steps in this section of the lab as well.
• Section: Configure browser settings to trust the adfsaccount federation server
  • You should get a certificate error in this step, since the certificate is self-signed. When prompted you can to install the certificate as instructed for the adfsweb site in a later step.
• Sections: Access the claims-aware application from a Windows XP client/Vista client
  • Either of these sections should behave similar though instructions to handle self-signed certificates are slightly different.
  • You may be prompted more than once to install certificates, as you are redirected to the adfsresource and adfsaccount servers. Be prepared to install several certificates.

Appendix A: Creating the Sample Claims-Aware Application

• The code for default.aspx and default.aspx.cs are fine in this section of the lab.
• The web.config does not work for IIS7, and this can really throw you for a loop because you’ll get a generic “Internal Server Error” at the client machine…with NO IDEA what is behind it. This happened to me and I assumed once again that I had missed a configuration step. Joe Kaplan and I spent a bunch of time trying to trouble shoot my configuration for AD FS on all machines, thinking that was the cause…and then he eluded it might be an IIS issue. It turns out that if you browse to the /claimapp from the web server machine you can see the full error. Thanks to my friend Richard Campbell for suggesting I try that one! Since I have custom errors turned off in the web.config, I should have been able to see the error remotely…but apparently something else (perhaps in IIS 7 defaults) is overriding that behavior. I’ll have to look into that separately.
• When I was able to see the full error, it pointed to a configuration issue in the web.config related to the HTTP module configuration for the Web Agent (screenshot below). A new section must be added to the web.config, inside the <configuration> element, as follows:

<system.webServer>
  <modules>
    <add name="Identity Federation Services Application Authentication Module" 
type="System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, 
System.Web.Security.SingleSignOn, Version=1.0.0.0, 
Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null" 
preCondition="managedHandler" />
  </modules>
  <validation validateIntegratedModeConfiguration="false" />
</system.webServer> 

I have to say, it was an interesting ride trying to get this lab set up, and as it turns out there aren't too many errors in the lab but the few missing and incorrect steps was enough to cost me 30 extra hours at least of preparation time. I hope you do not have the same problem with the tips I have provided here. I have to thank once again my friends Stephen, Joe and Richard for their respective roles in helping me work through the issues. Especially Joe who really went out of his way to help me review the AD FS setup, even though it turned out that the lab was not incorrect on that front...he gave me lots of great insight in the process, not to mention some cool tools that I could use to troubleshoot. You guys are the best!!!!

Supporting Resources:

• Joe Kaplan is one of the very few and strongest authorities on AD FS out there today, and he was a tremendous help to me as I got up to speed on the environment. His web site and forum are as follows:
  • http://www.joekaplan.net
  • http://directoryprogramming.net
• ADFS for Developers – a nice high level article from Keith Brown on ADFS (for 2003 server):
  • http://msdn2.microsoft.com/en-us/magazine/cc163520.aspx
• Understanding WS-Federation – to understand the protocols beneath federation, this is helpful:
  • http://msdn2.microsoft.com/en-us/library/bb498017.aspx

P&P is putting together guidance for WCF security and is looking for feedback from the community. Now is the time to influence the results from your own practical experience so get in there and review the whole thing or the areas of your greatest interest over the next few weeks! The feedback will be really useful!

J.D. Meier's blog has a link here:

http://blogs.msdn.com/jmeier/archive/2008/03/27/patterns-and-practices-wcf-security-guidance-now-available.aspx

Or, go direct to the CodePlex site:

http://www.codeplex.com/WCFSecurity/

Thank you very much for attending the presentation last night, I enjoyed all the great questions and discussion, and as promised here is a link to the slides, and resources for the presentation.

Get the slides here.

Get the code samples from my .NET Roadshow presentations on security, and this includes the federation samples, here: http://www.dasblonde.net/2007/09/15/NET35RoadshowSampleCode.aspx

Enjoy!

As some of you may know, several of us at IDesign (Juval, Brian and myself) are in the midst of a two-week .NET 3.5 Roadshow - six cities in two weeks where we collectively cover WCF, WF, WPF, CardSpace, federated and claims-based security concepts, and some key aspects of .NET 3.5 such as new C# 3.0 language features and ADO.NET 3.5 including LINQ and the Entity Framework.

I'm personally covering WCF security, federated and claims-based security, C# 3.0 and ADO.NET 3.5. For those of you attending (or, not) here are links to the code samples I'm presenting:

VS 2005 samples

• WCF Security Fundamentals - these samples come from the \Security directory from my book code
• Federated and Claims-Based Security in WCF - these samples come from the \Security\ClaimsBased directory from my book code
• CardSpace Samples

Download VS 2008 Samples (UPDATED 10/11/07)

This download includes all samples referenced above, in addition to .NET 3.5 samples for C# 3.0 and LINQ, and IDesign's declarative security model including a recent version of our ServiceModelEx library.  

Other relevant resources discussed:

• My WCF webcast series
• CardSpace controls for ASP.NET
• IDesign articles

Any questions? Email me.

-Michele

Here's a link to all my security demos, including some extra demos on claims-based security and CardSpace.

http://www.dasblonde.net/PermaLink,guid,1217187f-fe16-4426-9e38-a26552baedda.aspx

Martin Gudgin blogged about this last month...I just saw it, hilarious!

For my webcast today, I illustrated several layers of security features for ASP.NET with the following samples (some samples are extra beyond what we had time for in 1 hour):

• RBSWebUI.zip
• WindowsAuthentication.zip
• WindowsRoleBasedSecurity.zip
• StrongNamePermissionDemo.zip
• ASPNETSandboxing_updatedfor2.0.zip
• ASPNETSandboxing2_updatedfor2.0.zip

Also see my Publications page for articles on this subject for The Server Side .NET

In this session at Tech Ed in Boston last week, I discussed how you can apply Enterprise Services (COM+) and MSMQ to build scalable applications pre-WCF. The sample code that I demonstrated is listed below. Don't forget also to look at my Publications page to get more background, specifically the articles I wrote for The Server Side on security and sandboxing which discuss many of the EnterpriseServices features used.

• SimpleComponent.zip (51.19 KB) - Simple example of ServicedComponent
• SimpleQueuedComponent.zip (53.57 KB) - Simple queued component
• ASPNETSandboxing2_updatedfor2.0.zip - Fully features ASP.NET sample with serviced components, using features of COM+ including security, transactions, application configuration.

Enjoy!

Yes, at last, I am posting my code for my SDC conference sessions. I am quite sorry about this delay, but I have been travelling non-stop since the conference, and I had at least one million other deadlines upon me and Internet issues during the week following when I had promised to post. So, hopefully apology accepted...here is the code references for all 4 of my sessions!!!!

How ASP.NET 2.0 Processes Requests - Handlers, Modules, Caching, Session and other fun objects involved in the round-trip

• HttpHandlers.zip
• HttpHandlersVB.zip
• If you get ASP.NET Pro magazine, I also wrote an article on this subject, which was reprinted with permission in the SDC magazine for this conference

ASP.NET Security - It's About More than Just Credentials

• RBSWebUI.zip
• WindowsAuthentication.zip
• WindowsRoleBasedSecurity.zip
• StrongNamePermissionDemo.zip
• ASPNETSandboxing_updatedfor2.0.zip
• ASPNETSandboxing2_updatedfor2.0.zip
• Also see my Publications page for articles on this subject for The Server Side .NET

Applied ASP.NET 2.0 - Essentials for Building Professional Web Sites

• LookAndFeel.zip
• DataDemos.zip
• Navigation.zip
• ConfigurationUtility.zip
• Profiles.zip
• Globalization, Caching, Profiles, Themes Sample
• Also, see above links, which were also code samples demonstrated in this talk

Performance Tuning and Monitoring your ASP.NET Applications

• In this talk I covered a lot of ground, and theory around performance including the progression of asynchronous handlers to component distribution.
• You can look at my ASPNETSandboxing2 example above for component distribution.
• See also the DataDemos.zip above for data caching
• Rick Strahl did a great job documenting ASP.NET 2.0 threading model here
• Jeff Prosise and Fritz Onion wrote in-depth articles on the subject for 1.1 and 2.0 as well
• PerfCounters.zip
• HealthMonitoring.zip

In my tutorial yesterday here at DevConnections I tossed the slides for the last half (those are for your reference) and basically spent the time demonstrating varioius aspects of ClickOnce: deployment, versioning, security, download on demand, globalization and offline data deployment. Whew, even without slides that was a lot to cover, and we opened many a can of worms that just leads to additional questions on the entire lifecycle of a smart client app deployed with ClickOnce.

One thing that really hit home is the “rights” users have to install applications. There are a variety of answers to that question, some of which were only vaguely answered in our discussion, and one item I wanted to follow up on...which I did with my colleague Brian Noyes.

Q. Who can install a click once application?

Any user can click a link to a ClickOnce application and install the application. If the appilcation requires greater trust than the zone they are installed from will grant (Intranet, Internet, My Computer) they will be prompted to approve the installation.

HA! That's that part I wasn't expecting (thanks Brian)...because I thought that ClickOnce was secure by default, meaning...users can't just click “ok“ to accept the download and elevation of application privileges...apparently I'm wrong...and I could swear I remembered speaking to someone “who knew“ about this in the past...but my memory may fail me...too much stuff in there I guess.

Q. What's the prompt for?

The download prompt is for one thing only: do you want to elevate security of this application you are downloading, beyond the security settings for its zone?

Are you sure? Are you REALLY sure?

And away we go, the app gets all the security it needs to run...that is, if there is sufficient permissions to complete the installation...

Q. Are users ALWAYS prompted to elevate security?

They are prompted every time the application is updated if it requires additional permissions beyond what the zone allowed.

UNLESS...the certificate is installed in the trusted publishers section of the certificate store, and if the issuer of the certificate is installed in the trusted roots section. Administrators can push the certs out to machines within the domain so that users are not prompted to elevate security for trusted publishers.

For non-trusted publishers, users will continue to be asked...WHAT??!? Yep, users by default have the right to “decide“ if they want to trust an application...and yes, it could be an application that when run deletes that special project they have been slaving over...or some other malicious behavior... and all because they were asked a question to which they responded...

duh...ok!

Q. Can administrators protect users from downloading untrusted applications?

Yes. If the prompting behavior is turned off, only applications that are trusted (cert has been installed) will be allowed to elevate security. Other apps can only run within the confines of the zone they belong to. So, if you install the application with an MSI, you get My Computer zone, and that grants full trust by default. Internet or Intranet downloads are granted less.

To turn off prompting behavior, set up the registry key:

To make life difficult for users? no

To make life difficult for Mort? no

To make it difficult to accidentally trust a malicious third party and give them full access to the machine? yes, absolutely

So, administrators get your SMS push ready and get that registry setting up and running...pronto! Unless you don't concern yourself with the users ability to install apps to the corporate domain.

Conclusions:

• by default anyone can install an application and elevate trust unless admins turn off the prompting features
• applications that have publisher certificates installed are trusted to elevate security
• application installations over the Web or via MSI still may need administrative if the bootstrapper calls for adding components to the GAC, or downloading SQL Server Express which requires an admin as well...so ClickOnce is not necessarily removing the pain of installing complex applications...but it sure makes it easy for apps that don't require admin installation privileges
• in any case, once installed updates that don't bootstrap additional functionality that requires admin installation rights...can be easily handled by any user

Hope this is helpful to those that were new to ClickOnce...since we really couldn't get through all the nit picky details in my talk.

Please visit my collegue Brian's talk tomorrow for more:

Wed 2:00-3:15pm - VSM351: Secure Smart Client ClickOnce Deployments

Unless you want to come to my talk on Indigo/WCF security:

Wed 2:00-3:15pm - VID304: Indigo and Security: Experience the Magic

See you around!

Ok, so I just had a long discussion with one of the smartest guys I know, my colleague, mentor and friend - Juval. We were talking about strong names, full trust the global assembly cache and .NET assemblies. It started out innocently enough, however as the discussion continued, we both insisted on being right...and as it turns out, we were both right...but I still lost $1 due to my own muddy description of the bet. Perhaps you've been confused by this as well? Read on...

She said:

When you deploy assemblies to the GAC, they get full trust.

He said:

No, you're wrong. The GAC has nothing to do with the assignment of privileges. You want to bet? I can prove it.

She said:

No, I'm sure of this, I do it all the time with my ASP.NET applications when I deploy business objects to the GAC. They get full trust. This is important because it is the only way I can reduce the privileges of the ASP.NET application assemblies (using the <trust> element as I discuss in my article here: http://www.theserverside.net/articles/showarticle.tss?id=SandboxingComponents), and then elevate privileges as needed to invoke assemblies that demand full trust or other permissions. The stack walk would fail, if I were not able to elevate privileges at some point, and assert to circumvent the stalk walk. I certainly don't want ASP.NET application assembly to run with full trust if I can avoid it.

He said:

Ha, I'm right. You see?

So, he demos his client app (EXE), with a dependency on another assembly (DLL) that was deployed to the GAC. He removed full trust for assemblies deployed to local machine. Then he invoked a .NET assembly that required full trust. Sure enough, the permission demand fails.

She said:

Crap. Thinking thinking thinking...Well, wait a minute, you need the policy to at least grant full trust based on the strong name or something like that? Darn it, what is it? I know there is something...ok I didn't describe this right...(fumbling)...I mean...er...I wasn't trying to say GAC = full trust, but that you need to deploy to the GAC, at least with ASP.NET...to get full trust...hmmm...ok, here's your damn dollar.

ABOUT AN HOUR LATER

She said:

Aha! I went and reread my article (above) and it jogged my memory...basically, ASP.NET runtime uses different security policies to assign permissions. Inside the security policies for ASP.NET such as web_lowtrust.config, web_hightrust.config, etc...there is a setting that pulls in full trust for GAC assemblies, automatically.

                 <CodeGroup

                                class="UnionCodeGroup"

                                version="1"

                                PermissionSetName="FullTrust">

                            <IMembershipCondition

                                    class="UrlMembershipCondition"

                                    Url="$Gac$/*"

                                    version="1"

                            />

If only I could remember these things in the heat of discussion, I would be $1 richer right now.

Ok, you were right...but so was I :) Ego somewhat repaired.

Tonight was my turn to present as part of Regional Directors presentation month in southern california. Tim Huckaby presented at the San DIego .NET Developer's Group last week, I presented to the VBUG in Orange County (with a good collection of C# UG members also present), and Paul Sheriff is next, presenting to the San Diego .NET User Group the last week of January.

Tonight I test drove my latest materials on .NET 2.0 ClickOnce and related subject matters for Smart Clients such as offline connectivity and data storage, versioning and deployment, security evaluation and elevation, and so forth. The slide deck is in PPT format here:

versiondeploysmartclient20.zip (979.02 KB)

Related links I showed at the end of my talk:

http://www.idesign.net - See some of the .NET 2.0 webcasts delivered by my colleagues
http://www.dotnetdashboard.net/sessions/versiondeploy.aspx - see my resources on .NET 1.1 versioning and deployment

Other Microsoft resources for smart clients:
http://www.windowsforms.net
http://msdn.microsoft.com/smartclient 

I recently recieved this question from a SearchWebServices.com reader:

I am designing a sample app that has 3 tiers - Web browser, .NET application & DB server. I believe (correct me if I am wrong) that given that each individual user will not be connecting to SQL server directly (except maybe for DB Admin's etc) it is desirable to create a login for IIS to connect to the server and a user login to connect to the DB in question with the appropriate permissions. The .NET application will be connecting to the DB using ADO.NET. Is this true, or am I barking up the wrong tree?

Interestingly this is a subject I have been writing about recently. Here's the answer I posted for this question.

Let’s first clarify the physical tiers you describe here. The Web browser on the client tier, but really doesn’t participate in the description of tiers for the server-side application. Users will provide credentials through the browser that must ultimately be authenticated by IIS or passed through to ASP.NET for custom authentication. The .NET application I presume is hosted on the Web server physical tier, along with IIS. The database server physical tier hosting…well…the database application. potentially The server-side then has two physical tiers. If this is an intranet-based application, the Web site is likely configured for Windows authentication in IIS, which means IIS will authenticate the user within the Windows domain. Authorized requests will be forwarded to the ASP.NET runtime for processing, and if the application is configured to impersonate the authenticated user, application code will be governed by what the impersonated account is authorized to do:

<identity impersonate=”true” />

For example, if the logged in user is authorized to access the database (which really means, whichever database objects the account is granted access to, and for whatever type of access like db_datareader, dbdatawriter) then functionality to access the database will execute without exception. But this is not realistic as you mention. That means the code that tries to access the database must first impersonate an account that is granted appropriate access to the database objects. If the intranet application impersonates the logged in user, then this impersonation must be handled on the fly, and must be reverted so that the logged in user is once again the identity under which the remainder of the request thread executes.

If the application does not impersonate the logged in user, ASP.NET application requests will be executed with the ASP.NET identity configured in the <processModel> section of the machine.config. This is usually the NETWORKSERVICE account, which has limited privileges (by design). In theory you could have the application impersonate a higher privilege account for all requests that also has access to the appropriate database objects. BUT - DO NOT DO THIS. This is the lazy man’s solution to gaining access to protected resources, and it seriously compromises the safety of the application. If a hacker were to gain access to an executing thread inside the worker process, they will have access whatever privileges have been granted that thread. By default, we prefer this to be the NETWORKSERVICE account, or the account of the logged in user for intranet applications.

So, the solution?

• Either impersonate the logged in user or run the application under the NETWORKSERVICE account
• For calls to the database, either impersonate a privileged account at runtime, or use EnterpriseServices to invoke a serviced component that runs with the required account with database privileges (better). This decouples the configuration of the required account to access the database from the code, allowing it to be modified as needed through serviced component configuration (COM+). This also has the benefit that later you could distribute the database access component to another tier for scalability and security requirements.

What accounts do you need?

• It is useful to have an account that can only read the database (db_datareader privileges to appropriate objects), and another that can read and write (db_datareader and db_datawriter privileges). This way, during read operations you are not vulnerable to write attacks.

For more information on this subject, see my article on The Server Side.NET referenced here in my blog: http://www.dasblonde.net/PermaLink.aspx?guid=aa616d20-1089-4a24-8f0c-14326f2a731c