When I presented the Security Summit in Anaheim earlier this month, one of the attendees asked me how to override the 50 year authentication ticket. That's right, FormsAuthenticationTicket.Expiration is set to DateTime.Now.AddYears(50) by default. This propagates to the HttpCookie returned with the response as well.

Well, I don't know about you but I'm highly doubting that I'd need a ticket to last me 50 years, so here is the code to workaround this (rather lame) default setting.

Dim redirectUrl As String = FormsAuthentication.GetRedirectUrl(userName, False)
Dim authCookie As HttpCookie = FormsAuthentication.GetAuthCookie(userName, True)
authCookie.Expires = DateTime.Now.AddMinutes(20)
Response.Cookies.Add(authCookie)
Response.Redirect(redirectUrl)

I'd probably go ahead and externally configure the 20 minute timeout interval as well. Oh, and I believe this also resolves the incompatibility issue with other browsers that don't quite know what to make of the 50 year token.

In the code sample that started these recent blog posts, I was using GetHashCode() to display a unique value for a thread in a simple example, for visually unique identifier for a thread, without bothering to set the Thread.Name property. For this simple type of example, GetHashCode() has always done the trick (and I've always referred to this as the logical thread ID) because I didn't care if I was displaying the physical (Win32) thread ID, accessible via AppDomain.GetCurrentThreadId(). In an application that requires maintenance of a list of running threads, I usually set the Name of each thread (better for debugging as well) and hold on to each Thread reference:

ThreadStart del = new ThreadStart(Start);
Thread t = new Thread(del);
m_newThreads.Add(t); // ArrayList scoped globally
t.Name="Thread #" + m_newThreads.Count;
t.Start();

To display thread information:

this.listBox1.Items.Clear();
foreach (object o in m_newThreads)
{
 Thread t = (Thread)o;
 this.listBox1.Items.Add(t.Name + ": " + t.GetHashCode());
}

Notice that from each thread reference t I cannot access the physical thread ID since such a property doesn't exist on the Thread type. If I required this information I could always create a thread wrapper class that returns this information using AppDomain.GetCurrentThreadId().

This sample demonstrates this and a few other things related to the subject of process and thread identities. For example, you'll note that the process identifier accessed through Process.GetCurrentProcess().Id always returns the same process ID, whereas Process.GetCurrentProcess().GetHashCode() returns a different value for each thread. This is not because they are running in a different process but because the underlying code for GetCurrentProcess actually creates a new Process object reference based on the actual physical process:

return new Process(".", false, NativeMethods.GetCurrentProcessId(), null);

Of course, consistent with the purpose of GetHashCode() discussed in Lazy Blogger's references, this generates (you guessed it) a new hash code for the object reference.

Ok, per my last post, James points out the following hilarious truth, that there is actually a setting in Visual Studio to prevent people from getting scared of methods and properties they don't understand:

Now I am really laughing my head off! I had no idea this option existed, thanks James!

And so I add a new category to my blog...titled: what the? Because sometimes, you just have to ask the question...WHY?

<what the?>
One of the main draws of the .NET Framework is that regardless of language preference, we can all share a common object model to access core features. So why did I just waste 5 minutes hunting down how to get the thread ID using VB.NET? Because instead of using GetHashCode() which I'm accustomed to in C#, I have to use the oh-so-convenient AppDomain object's GetCurrentThreadId() method. I mean seriously, it is not even available from the Thread object?

Granted, Thread.ThreadID might have been a nice property, to replace GetHashCode(), but what's good for the goose...oh, I get it...this:
AppDomain.GetCurrentThreadId()

Is much easier to understand than:
Thread.CurrentThread.GetHashCode()

That is, if you can find it...
</what the?>

In many presentations of late I have mentioned to folks the preference of Enterprise Services over .NET Remoting. In part to reduce the risk associated with rolling your own security model across boundaries (among other things), and due to the fact that the Indigo team at Microsoft recommends Enterprise Services as the way to build your component architecture today, to better migrate to Indigo tomorrow.

Here are some references I found on the subject on Rich Turner's blog (he's a PM) and a video on the MSFT site. If I find more, I'll add to comments. If you have your own proof, or have questions/concerns on this subject, YOU add to comments :)

• http://blogs.msdn.com/richturner666/archive/2004/03/05/84834.aspx
• http://blogs.msdn.com/richturner666/archive/2004/03/05/84771.aspx
• Indigo Migration Webcast

Cheers.

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.