ASP.NET application services are built-in Web services that provide access to features such as forms authentication, roles, and profile properties. These services are part of a service-oriented architecture (SOA), in which an application consists of one or more services provided on the server, and one or more clients.
Client applications for ASP.NET application services can be of different types and can run on different operating systems. These include these following types of clients:
Hosting ASP.Net application Services in Azure is no different from hosting in on-premise server. The scenario that I've discussed in this blog is ASP.Net Client Application Services set-up and it's handling of cookies.
<add name="myConnection" connectionString="Server=tcp:blah.database.windows.net,1433;Database=ASPNetDatabase;User ID=user@blah;Password=blah;Trusted_Connection=False;Encrypt=True;" providerName="System.Data.SqlClient"/>
<forms protection="Validation" cookieless="UseDeviceProfile" timeout="1" slidingExpiration="false" />
<roleManager enabled="true" defaultProvider="CustomSqlRoleProvider">
<add name="CustomSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="myConnection" applicationName="myApplication" />
<membership defaultProvider="SqlMembershipProvider" hashAlgorithmType="SHA1">
<add applicationName="myApplication" connectionStringName="myConnection"
enablePasswordReset="true" enablePasswordRetrieval="false" passwordFormat="Hashed"
requiresUniqueEmail="false" passwordAttemptWindow="5" passwordStrengthRegularExpression=""
name="SqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" />
There are two steps to it, first make sure that cookie timeout is properly set in the forms element as shown below.
Note: slidingExpiration should be set to false. Otherwise, for every successful login (like user validation) attempt by the user - last activity time and hence cookie time out gets reset. For more information, read MSDN documentation here.
The next step is to check for the cookie expiration and one of the ways to do it is to call GetRolesForUser for the logged in user. The key to this is that all the valid users should be assigned to roles. If no roles are returned, the login has expired. For more information, read MSDN documentation here.
Here's some sample code:
System.Security.Principal.IIdentity identity =
// Return if the authentication type is not "ClientForms".
// This indicates that the user is logged out.
if (!identity.AuthenticationType.Equals("ClientForms")) return;
ClientRoleProvider provider =
String userName = identity.Name;
// Determine whether the user login has expired by attempting
// to retrieve roles from the service. Call the ResetCache method
// to ensure that the roles are retrieved from the service. If no
// roles are returned, then the login has expired. This assumes
// that every valid user has been assigned to one or more roles.
String roles = provider.GetRolesForUser(userName);
if (roles.Length == 0)
"Your login has expired. Please log in again to access " +
"the roles service.", "Attempting to access user roles...");
if (provider.IsUserInRole(userName, "Power Users"))
MessageBox.Show("User is still active");
"Unable to access the remote service. " +
"Cannot retrieve user roles.", "Warning",
Note: Some developers would try IsInRole method of the role service to check for expiration but it doesn't work always. The IsInRole method will always return false if the user login has expired. This will not occur if your application calls the IsInRole method one time shortly after authentication.
The sample project that I used is available for download!