July 28, 2008 at 10:03 AM
Recently I have been developing numerous applications in ASP.NET and Flex Builder 3. For security I utilized forms authentication as provided by ASP.NET engine. At first, everything worked well until there was a need to manually sign out current user. Quick look into MSDN documentation revealed SignOut() method of FormsAuthentication class. The documentation promised that this method signs out the user and redirects the client to login page. Considering the fact that I did not care about redirect (Flex application was running on the client side, so that redirection did not have any effect), I was hoping that the method would still perform desired effect and "de-authenticate" (I know, I know, that is not even a word) current user. At first, it seemed to work, but debugging revealed that even though this method removed authentication cookie, it did not sign out the user. User's identity was still marked as authenticated and subsequent calls to the Http handler would be considered authenticated. Furthermore, the session object was still valid, so that existing session information was still available. Quick look into MSDN revealed Session.Abandon() method, which would destroy session object upon execution. However, even though the session object was destroyed, client calls to ASP.NET web application were still considered authenticated. It was time to search the web to see if other developers faced the same issue.
After some research I ran into following Microsoft article: http://support.microsoft.com/kb/900111. The article explains that FormsAuthentication.SignOut() method does not prevent cookie reply attack, which essentially means that the cookie, even though it was destroyed, it was considered to be valid and all calls to the application that utilized this particular cookie were considered authenticated. The same article presented some possible workarounds, but it did not satisfy my needs. It bugged me that in order to prevent the access to secure parts of the application (even after log off), I had to track the security on client side (in addition to server side). So I tried following code:
/* Create new session ticket that expires immediately */
FormsAuthenticationTicket ticket =
/* Encrypt the ticket */
string encrypted_ticket = FormsAuthentication.Encrypt(ticket);
/* Create cookie */
HttpCookie cookie = new HttpCookie(
/* Add cookie */
/* Abandon session object to destroy all session variables */
Essentially the code replaces old cookie with new security cookie that expires immediately, which performs user sign out. In addition, all session variables are destroyed and new session is created so that old session cannot be reused. However, it is essential to mention that the technique presented in this post does not prevent Cookie Reply Attack. The old cookie is still valid for the duration specified in FormsAuthenticationTicket constructor.
July 11, 2008 at 9:07 PM
Unlike Silverlight, Flex Builder does not integrate with Visual Studio programming environment. Therefore, debugging ASP.NET or Flex applications can become very cumbersome, especially when they become very large. However, with Flex Builder 3, Adobe has made possible to utilize built in ASP.NET web server (Cassini) to debug Flex applications. Following post describes one possible way to set up both environments to make debugging easier.
June 27, 2008 at 8:45 AM
Lately, Adobe Flex has been getting more and more attention in programming community. Especially after the launch of open source version of Flex SDK developers are able to make rich Internet applications (RIA) using Flex, which (as everybody knows) produces a flash file (swf) that can be used in any web application. The article will focus on the following topics:
- Communication between Action Script (HTTPService) and .NET (HTTP Handler);
- Security - securing HTTP Handler calls from unauthorized access;
- ASP.NET Forms Authentication and Authorization through Flex;
- ASP.NET Handlers and session management;
It is assumed that the reader is familiar with basic concepts of ASP.NET handlers, forms authentication, and Adobe's Action Script.
May 31, 2007 at 6:59 PM
Authentication and authorization as fundamental part of a web application was tremendously simplified with arrival of .NET 2.0. Basic authentication and authorization can be performed using different DBMS systems. There are numerous examples implementing authentication using Access database. One such example can be found in the article ASP.NET 2.0 Authentication using Access Database. In this article the example implements bare minimum to achieve desired goal, namely authentication and authorization using access database. However, authentication and authorization is only first part of the user management system. Second fundamental part of user management is allowing users to create an account at will. In such instances, users can sign up and become members of the community without administrator intervention. Furthermore, the user should be able to provide contact information (email) so that he/she can be contacted if necessary. Contact information must be verified. This article focuses on very simple ways to achieve such goal.
March 4, 2007 at 5:56 PM
Authentication and authorization is one of the basic components of web application development. When I first started web development, I quickly realized that authentication and authorization of resources were performed in variety of ways. Throughout years, I developed variety of web applications, primarily for my own use. With arrival of ASP.NET 1.0, authentication and authorization were simplified. ASP.NET 2.0 takes this feature even further by providing the user with powerful tools to quickly implement authentication and authorization. With these tools, a user can utilize MS SQL 2005 Server, XML data source, MS Access database and other data sources to retrieve user information. In this article I will focus on bare minimum needed to implement forms authentication using access database.