I wrote this article describing how to leverage Enterprise Services for a scalable Web application:
http://msdn.microsoft.com/asp.net/community/authors/mlb/default.aspx?pull=/library/en-us/dnaspp/html/aspnetscal.asp

In the article post on MSDN, the SQL script is missing from the installation so, I reviewed the sample tonight, and decided to write up some instructions to help you run the code as well. Download this here:
ASPNETScalability.zip

Ok, so there isn't much here yet, but after that really long stretch of no sleep preparing for the interoperability event I pulled together last month finally the blog site www.interopwarriors.com is now live. Now we have a home for our random thoughts on the things we learned, and things we'll do before the next event. You can expect code, but not really soon, how about in July? After another long rush of deadlines is over?

Thank you to everyone who attended the Security Summit in Anaheim this past Tuesday.

I promised you some links to resource sites, and here is my page devoted to the event:

http://www.dotnetdashboard.com/sessions/securitysummit.aspx

Here you will find links to the official Microsoft site for the event and the resources provided by Microsoft. I pulled some of the Microsoft links for topics mentioned throughout the day and put them on this site so you can find them more easily.
In addition, I have supplied a number of my own resource sites that will lead you to code samples I presented, in addition to more advanced samples.

If you have any questions, let me know!

A the Security Summit this week, several people asked me about the .mspx extension Microsoft uses for some of its resources. You can create a custom HTTP handler to process requests for custom extensions. That means you first have to register IIS to pass request for that extension to ASP.NET. This article mentions how to do this. Then, you create a custom handler to process the request, by registering an HTTP handler or handler factory (see more resources on handlers and factories) to do the work. The handler factory's job is to return the right HTTP handler for the request, so ultimately, you are building a handler. The handler might even generate HTML on the fly.

In the case of .mspx extensions, Microsoft uses this extension to generate XML-driven HTML content. This article talks more about the architecture.

http://www.microsoft.com/backstage/bkst_column_46.mspx

In less than 10 minutes I just created a VB.NET demo for an upcoming SearchVB.com webcast, using WSE 2.0. Policy rocks! However...even though I've been through this before, once again I was momentarily baffled by the fact that my service seemed to be authorizing my UsernameToken even though I submitted a bad password. Well, that's the policy cache baby!

Steps to create the sample:

• Create a Web service project, enable WSE 2.0 extensions for the service
• Add a custom UsernameTokenManager class to handle, well, UsernameToken authentication.
• Add code to authenticate by performing a database lookup and returning the password from the AuthenticateToken method. In this case, I'm just returning password, clearly not a real example.

  Public Class CustomUsernameTokenManager
   Inherits UsernameTokenManager
  
   Protected Overrides Function AuthenticateToken(ByVal token As UsernameToken) As String
     Return GetUserPassword(token)
    End Function
  
  End Class
  

  Even without specifying a service side policy that requires a UsernameToken, the UsernameTokenManager will be invoked on each request and will validate the <wsse:UsernameToken> element passed with any requests. You should specify a policy as a best practice

• Create a Windows Forms client, add WSE 2.0 support BEFORE you add a Web reference to the Web service just created. This ensures that you get a WSE-aware proxy class.
• Add a couple of textboxes and a button to the Form, and handle the button click event by creating an instance of the WSE-enabled proxy, and invoking the service.
• Create a policy for the client to require UsernameToken signature
• Add code BEFORE invoking the WebMethod to create a UsernameToken object, and add it to the policy cache. Note: Here you'll notice that I'm clearing the cache before adding the token to the cache. This is where you'll run into trouble since the cache is not cleared unless you explicitly clear it.

    Dim svc As New localhost.Service1Wse
    Dim userToken As New
     UsernameToken(Me.TextBox1.Text, Me.TextBox2.Text, PasswordOption.SendNone)
  
    PolicyEnforcementSecurityTokenCache.GlobalCache.Clear()   PolicyEnforcementSecurityTokenCache.GlobalCache.Add(userToken)   Dim s As String = svc.GetSecret()

This brings up an interesting point about the policy cache. When should you populate it? When should it be cleared? Should we create policy cache managers that handle updating existing tokens when a new password is supplied?

Of course, this is a demo, so on most occasions, we wouldn't happily modifying passwords for the same user during the same session. However, a new UsernameToken is still added to the cache even if it refers to the same user, so beware of a) bloating the cache with tokens, and b) sending the wrong token (the first on in the cache wins!). In short, based on your client application, determine an efficient way to keep the cache free of junk. Perhaps store the token in the cache at login time, and reuse that token for each Web service request.

I just had an email exchange with the famous Kimberly Tripp (who is rumored to be blogging soon, look out!) about best practices for setting up security architecture for distributed Web applications and services. My eyebrows were raised at some demo code I saw that used a hard-coded account for ASP.NET to impersonate:

<identity impersonate=true userName=dbaccess password=whatever />
The names of the accounts have been hidden to protect the source of the demo ;)

I know, it's only a demo, but people use this stuff so I gave some thought to what I would do, and checked in with my pal Kimberly to see what she would do on the SQL side.

First of all, the ASP.NET worker process runs under the identity as configured in the <processModel> setting by default. (BTW this is a low privilege account that should probably be renamed since all potential attackers will know the default account name for default ASP.NET system deployments.) This account has access to the temporary ASP.NET file folder, so if you use impersonation, you may be required to give impersonated accounts access to the same folder, depending on what resources the Web application accesses. IMHO, database access accounts have no business being related to the ASP.NET worker process account, in terms of permissions, in general. Besides, there is likely to be a separate application server that handles all business logic including database access. Also, attack prevention is about adding layers of protection, and isolating resource ownership, so it makes more sense to let the ASP.NET worker process run under its account, and create appropriate accounts for database access (admin, readonly, readwrite, writeonly) that are configured in SQL server with appropriate permissions. Another further consideration is scalability with impersonation when invoking database resources. Connection pooling is isolated by security context.

So, if we don't want to impersonate, how do we access the database resource through a Windows account? Also, should we use Windows accounts? Kimberly says: In general the best way to protect access is to allow Windows authentication only, making sure that the sa account has a strong password (regardless of it being disabled). Also be sure to keep the sa account as a back door in the event that Admin accounts are removed from the Windows ACL list (inadvertently, but possible) so that you still have access to DB resources.

So, your Windows ACLs will include perhaps a few limited privilege accounts that are specifically configured in SQL server for read and/or write access to specific tables. These accounts can also be used as the identity under which various components in your DALC layer (probably serviced components) run, thus they are able to propogate credentials to SQL when invoking ADO.NET calls. If the serviced component (living on the application server tier) is securely invoked by the ASP.NET application front end (living on the Web server tier) because the application has verified the user's credentials (custom role-based security for typical non-Intranet application) and verified they (or the application) has the right privilege to invoke the DALC component...we are good to go.

Of course, every application deserves its own architecture review, so the real point of this short note is:

• Impersonation adds configuration overhead,
• Design for distribution of your Web application components, thus expect to require a secure invocation across tiers (Enterprise Services, registered components),
• Have a trusted component run with appropriate identity to talk to the database, so that credentials are propogated through integrated Windows security between components and SQL Server. One way to do this is to use a registered COM+ component (Enterprise Services) as the DALC layer,
• Configure limited access Windows accounts for this communication to reduce the affect of any potential hacker exploits (if they can even get this far down the pipeline, past your DMZ to the application tier presumably)
• Limit the number of Windows accounts configured in SQL to control access to resources, to optimize connection pooling

Nuff said.

After a long stretch focusing on my Web services materials, this week I switch gears to .NET security 100% time. I'm teaching 8 hours of .NET Security (the IDesign way) at UCSD Extension, plus I'm preparing for the Microsoft Security Summit (event links are on my .NET Dashboard site).

My point? You can expect blogging to focus on security for this next week or so...stay tuned.

Thanks to everyone for getting up so early (two days in a row, some of you!) to attend this session! The resources for this talk are here:

• Globalization Resource Page

The latest code is up there now!

Thanks to everyone for getting up so early to attend this session! Wow, what a turn out! The resources for this talk are here:

• HTTP Handlers Resource Page
• SOAP Extensions Resource Page

The latest code is already uploaded to the site, and more samples are bound to be there soon...

This talk started out with a bang as Don and Doug collected a list of questions from the audience that they planned to answer throughout. The best part about this was that the questions were really great. For example: When should you use .NET Remoting vs. Enterprise Services? What will happen to COM+? When does COM matter? Should we use ASMX?.

After this, they proceeded to go through exactly 3 slides. Cool bullets…

• There is only one program and it is still being written.
• Choice is an illusion.
• Objective interpretation is an oxymoron.

The question is, what do the bullets really mean? Clearly, Don and Doug are great philosophers who enjoy abstracting the meaning of technology, where have we been, where are we going, how do we get there…all that. So, I’ll give you my interpretation (which we know from the bulleted list will not be shared by everyone).

First of all, the meaning of SOA (something the masses struggle with big time) is that we need to design systems (or, services) as well encapsulated, autonomous chunks of functionality that can be consumed by other systems, across departmental, enterprise, and possibly industry boundaries. This is one big program (the matrix anyone?)…metaphorically speaking…although of course not literally. If we design systems with the expectation that we cannot control where and who consumes them, we will fit within the SOA model. Contracts for these services, once published, must remain constant…because we have no idea who is consuming them, nor when.

In a related topic of discussion regarding the definition of service interfaces, we must consider that there can be many interpretations of a service schema. For example, if an industry like ACORD (for insurance) defines what XML looks like for a certificate of insurance, does that mean all systems following that standard will interpret EVERY element of the schema in the same way? Or, might there be different (valid) renditions of this schema? For example, could an xsd:int value be delivered as an xsd:string instead and still be meaningful? Sure it can. Could a subset of the schema be used by the destination endpoint? Absolutely. Thus, by definition we need extensibility and we need to be prepared for variant interpretations. In addition, the object model behind a service will rarely look exactly like xsd-generated classes. Services must be able to interpret XML payloads in their own way, and process them according to the needs of the system. What all of these competing Web service vendor platforms can agree on is the goals of SOA and the protocols (WS*) that are required to interoperate. Proof of this of course is in my recent experience with the Web Services Interoperability Education Day. This is exciting stuff, to see emerging standards work across platforms…we will continue on our quest there.

I enjoyed the philosophy shared during the talk, but must admit that the questions asked at the beginning were so compelling that I was really looking forward to their answer. I almost think they could have done two complete presentations. One for the philosophy, another for the Q&A. So, although there wasn’t a lot of time for answers at the end, here’s a summary of what I captured:

• COM will not disappear, it will be part of hybrid solutions, and transparent to the service interface.
• Remoting is useful for crossing app domains, but not for crossing machine boundaries. Use it for fault tolerance within a process (one app domain goes down, the main process stays alive).
• Crossing machines and processes, DCOM is fastest binary protocol, and can be secured, which means EnterpriseServices (ES). This also facilitates DTC transactions. Oh, and MSMQ is integrated here so you can also guarantee message delivery.
• On ASMX serialization vs. binary serialization with remoting, ASMX will be faster than .NET remoting, short term performance gains using remoting today will not position your applications for future releases (I.e., Indigo). You can expect better performance with ASMX in future as programming models change, and frankly what impacts performance most is usually bad architecture, including hardware choices and physical tier distribution. One thing that will also support performance improvement at a more granular level is also XML parsers…something the team is working on.
• How many WS* protocols do we need? Less. SOAP/XML is a great start. WS-Security is critical for end to end message integrity. We need standard protocols for interoperability, thus we need tools to assist with serialization, such as WSE 2.0.
• WSE 2.0 gives us a chance to work with WS* protocols now, while waiting for Indigo. The important thing is to realize it is taking you in the right direction. It keeps you in the game. These standards move fast, so does the WSE team. Indigo will just swallow it all making it even easier once standards are more stable.
• MTOM is the future of DIME.
• SAML will be supported, because WSE is extensible. Actually, Benjamin Mitchell and I worked on a SAML sample for our interoperability demonstration with Axis/SourceID…so we kinda already have a start on that!
• Your ES investment with COM+, MSMQ will be supported by the world of Indigo. Of course!