Update: The original answer provided was with a project using MembershipProvider and it's explained in the answer itself. I, the asker, am not using it, so the answer to my problem was slightly different but extracted from this answer. I'm putting my answer at the bottom for anyone that cares and leaving the original verbatim, as it contains a lot of value.
Yes, you can use FormsAuthentication for your own strategy. And while the asp.net db structure does not suit you, you may provide a simple implementation of MembershipProvider to allow use of the Membership infrastructure. These two functionalities are not married so you may decide what fits for you.
Keeping in mind your question and some of the comments, here is a runnable example of how simple it is to leverage the provider model without being married to the default implementations and db schemas.
Using forms auth for your own purposes is simple. You just need to provide authentication and set your own ticket (cookie).
Using custom membership is almost as simple. You can implement as little or as much of the provider as you need to support the asp.net infrastructure features that you would like to employ.
e.g. in the sample below, I show that in the login process you may simply handle an event on the login control to validate credentials and the set the ticket. Done.
But I will also show how leveraging the provider model and implementing a custom membership provider can result in stronger, cleaner code. While we are in the custom membership provider I implement the minimum necessary to support using the Membership subsystem to provide easy access to a user's meta data without the need to write your own infrastructure.
Just drop these files into an empty project.
web.config
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation debug="true"/>
<authorization>
<deny users="?"/>
</authorization>
<authentication mode="Forms"/>
<!--
optional but recommended. reusing the membership infrastructure via custom provider divorces
you from the aspnetdb but retains all of the baked in infrastructure which you do not have to
develop or maintain
-->
<membership defaultProvider="mine">
<providers>
<add name="mine" type="CustomAuthRepurposingFormsAuth.MyMembershipProvider"/>
</providers>
</membership>
</system.web>
</configuration>
Site1.Master
<%@ Master Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
<asp:ContentPlaceHolder ID="head" runat="server">
</asp:ContentPlaceHolder>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:LoginName ID="LoginName1" runat="server" />
<asp:LoginStatus ID="LoginStatus1" runat="server" />
<asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
</asp:ContentPlaceHolder>
</div>
</form>
</body>
</html>
Login.aspx
<%@ Page Title="" Language="C#" MasterPageFile="Site1.Master" %>
<%@ Import Namespace="CustomAuthRepurposingFormsAuth" %>
<script runat="server">
/*
* If you don't want to use a custom membership provider to authenticate
* simply place your logic in the login control's handler and remove the
* membership element from config. It would have to take a very very
* compelling edge case to motivate me to not use a custom membership provider.
*
*/
//protected void Login1_Authenticate(object sender, AuthenticateEventArgs e)
//{
// // perform mindbendingly complex authentication logic
// e.Authenticated = Login1.UserName == Login1.Password;
//}
/*
* set your cookie and you are golden
*/
void Authenticated(object sender, EventArgs e)
{
// this is an arbitrary data slot you can use for ???
// keep cookie size in mind when using it.
string userData = "arbitraryData";
Response.Cookies.Add(TicketHelper.CreateAuthCookie(Login1.UserName, userData, Login1.RememberMeSet /*persistent cookie*/));
}
</script>
<asp:Content ID="Content1" ContentPlaceHolderID="head" runat="server">
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">
<asp:Login ID="Login1" runat="server" OnLoggedIn="Authenticated" >
</asp:Login>
username==password==authenticated. <br />e.g.: uid: me, pwd:me
</asp:Content>
Default.aspx
<%@ Page Title="" Language="C#" MasterPageFile="Site1.Master" %>
<%@ Import Namespace="System.Security.Principal" %>
<%@ Import Namespace="CustomAuthRepurposingFormsAuth" %>
<script runat="server">
protected void Page_Load(object sender, EventArgs e)
{
/*
* you get this for free from asp.net
*/
HttpContext page = HttpContext.Current;
IIdentity identity = page.User.Identity;
string username = identity.Name;
bool authenticate = identity.IsAuthenticated;
// or use the Request.IsAuthenticated convenience accessor
/*
* you get this really cheap from forms auth
*
* cost: validating credentials and setting your own ticket
*/
// this page is protected by formsauth so the identity will actually
// be a FormsIdentity and you can get at the user data.
// UserData is an appropriate place to store _small_ amounts of data
var fIdent = (FormsIdentity)identity;
string userData = fIdent.Ticket.UserData;
// so, using only forms auth this is what you have to work with
LblAuthenticated.Text = page.User.Identity.IsAuthenticated.ToString();
LblUserId.Text = page.User.Identity.Name;
LblUserData.Text = userData;
/*
* this is an example of using a custom membership provider and subclassing the
* MembershipUser class to take advantage of the established mature infrastructure
*
* this is entirely optional, you can delete the Membership section in web.config
* and delete MyMembershipProvider and MyMembershipUser and just use the authentication.
*
*/
// get the custom field
string myCustomField = ((MyMembershipUser)Membership.GetUser()).MyCustomField;
LblMembership.Text = myCustomField;
}
</script>
<asp:Content ID="Content1" ContentPlaceHolderID="head" runat="server">
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">
<br />
Authenticated:<asp:Label ID="LblAuthenticated" runat="server" Text=""></asp:Label><br />
UserId:<asp:Label ID="LblUserId" runat="server" Text=""></asp:Label><br />
UserData:<asp:Label ID="LblUserData" runat="server" Text=""></asp:Label><br />
<br />
Membership User Custom Field:<asp:Label ID="LblMembership" runat="server" Text=""></asp:Label><br />
</asp:Content>
CustomAuthClasses.cs
using System;
using System.Web;
using System.Web.Security;
namespace CustomAuthRepurposingFormsAuth
{
public static class TicketHelper
{
/// <summary>
///
/// </summary>
/// <param name="userName"></param>
/// <param name="userData">be mindful of the cookie size or you will be chasing ghosts</param>
/// <param name="persistent"></param>
/// <returns></returns>
public static HttpCookie CreateAuthCookie(string userName, string userData, bool persistent)
{
DateTime issued = DateTime.Now;
// formsAuth does not expose timeout!? have to hack around the
// spoiled parts and keep moving..
HttpCookie fooCookie = FormsAuthentication.GetAuthCookie("foo", true);
int formsTimeout = Convert.ToInt32((fooCookie.Expires - DateTime.Now).TotalMinutes);
DateTime expiration = DateTime.Now.AddMinutes(formsTimeout);
string cookiePath = FormsAuthentication.FormsCookiePath;
var ticket = new FormsAuthenticationTicket(0, userName, issued, expiration, true, userData, cookiePath);
return CreateAuthCookie(ticket, expiration, persistent);
}
public static HttpCookie CreateAuthCookie(FormsAuthenticationTicket ticket, DateTime expiration, bool persistent)
{
string creamyFilling = FormsAuthentication.Encrypt(ticket);
var cookie = new HttpCookie(FormsAuthentication.FormsCookieName, creamyFilling)
{
Domain = FormsAuthentication.CookieDomain,
Path = FormsAuthentication.FormsCookiePath
};
if (persistent)
{
cookie.Expires = expiration;
}
return cookie;
}
}
/// <summary>
/// This is an example of inheriting MembershipUser to
/// expose arbitrary data that may be associated with your
/// user implementation.
///
/// You may repurpose existing fields on the base and add your own.
/// Just perform a cast on the MembershipUser returned from your
/// MembershipProvider implementation
/// </summary>
public class MyMembershipUser : MembershipUser
{
public MyMembershipUser(string providerName, string name, object providerUserKey, string email,
string passwordQuestion, string comment, bool isApproved, bool isLockedOut,
DateTime creationDate, DateTime lastLoginDate, DateTime lastActivityDate,
DateTime lastPasswordChangedDate, DateTime lastLockoutDate)
: base(
providerName, name, providerUserKey, email, passwordQuestion, comment, isApproved, isLockedOut,
creationDate, lastLoginDate, lastActivityDate, lastPasswordChangedDate, lastLockoutDate)
{
}
protected MyMembershipUser()
{
}
// e.g. no desire to use Profile, can just add data
// say, from a flat record containing all user data
public string MyCustomField { get; set; }
}
/// <summary>
/// At the most basic level, implementing a MembershipProvider allows you to
/// reuse established framework code. In this case, we just provide services
/// for the Login control and user identification via Membership subsystem.
/// </summary>
public class MyMembershipProvider : MembershipProvider
{
#region Minimum implementation in order to use established authentication and identification infrastructure
/// <summary>
/// You can just do this in the login logic if you do not want
/// leverage f
