Sebastian Leupold wrote
DotNetNuke uses Microsoft Membership Component (Usee MSDN), but not all aspects. For implementing SSO you will either need to analyse, how DNN implements membership or use webservices like iWEB project (see on DNN forge) does.
Sebasitian i finally figured it out
this is how it will be done
i tested it
The Simplest Forms Authentication Application
To setup basic forms authentication in ASP.NET, create a web application called app1 with two pages called
default.aspx (a protected resource) and login.aspx (a public resource used to log the users into app1) on
your local host.
The Login Page
The login.aspx page only needs to contain a few .NET controls2:
protected System.Web.UI.WebControls.TextBox txtUsername;
protected System.Web.UI.WebControls.TextBox txtPassword;
protected System.Web.UI.WebControls.Button btnLogin;
protected System.Web.UI.WebControls.CheckBox chkPersist;
protected System.Web.UI.WebControls.Label lblError;
The users can enter their username and password in the two text boxes (txtUsername and txtPassword.)
Should they want to be issued a permanent cookie, the users can select the check box to avoid having to relog
into the application at each new session (chkPersist.) They submit by clicking on the login button
(btnLogin.)
The btnLogin handler for the login button works as follows:
private void btnLogin_Click(object sender, System.EventArgs e)
{
if (Page.IsPostBack)
{
if (true == CheckedUser(txtUsername.Text, txtPassword.Text))
{
FormsAuthentication.RedirectFromLoginPage(txtUsername.Text, chkPersist.Checked);
}
else
lblError.Text = "Unkown user name or wrong password!";
}
}
1 In case this preferred order has been overlooked, it is still possible to re-register ASP.NET after installing IIS 5.0. Simply run the
aspnet_regiis.exe command-line utility located in the %WINDOWS%\Microsoft.NET\Framework\v1.1.4322 system
folder.
2 Cf. Appendix A – App1 Code, page 14.
ASP.NET Single Form Authentication Sign-on 4
3/22/2005 © Philippe Lacoude
The CheckedUser function can be any process that checks the validity of the user’s password and returns true
or false. The RedirectFromLoginPage method issues an authentication ticket and stores it in a cookie whose
persistence depends on the checkbox’s value.
The Web Application Configuration
The cookie configuration is read from the Web.config file. The XML-based syntax of this file must contain
at least two sections, <authentication> and <authorization>, for the forms authentication to function
properly.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<authentication mode="Forms">
<forms name=".ASPXAUTH" loginUrl="/app1/login.aspx" protection="All" timeout="20" path="/" />
</authentication>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</configuration>
The <authentication> section specifies that the process of accepting credentials from a user – and of
validating these credentials against a designated authority –, relies on Forms (rather than on Windows, Passport
or None.) When using forms authentication, the section must have a <forms> XML sub-node to set the
properties of the authentication cookie. The <forms> section path attribute determines the scope of the
cookie: a path equal to "/" means that the cookie is valid for all pages under the root of the web site. In
other words, such a path means that the cookie will be presented to all pages of all applications.
The <authorization> section lets us specify who has access to the ASP.NET resources located in the app1
folder. In our case, we <deny> access to unauthenticated users ("?").
The Protected Page
There are no particular Forms Authentication settings to add to our protected resource (which, in our case,
will be default.aspx). For illustration purposes, we can add a text label called lblHello and display the
name of the currently logged on user:
private void Page_Load(object sender, System.EventArgs e)
{
lblHello.Text = "Hello, " + Context.User.Identity.Name;
}
This completes our sample application. A request to the http://localhost/app1/ link is automatically
redirected to the login page. Upon entering proper credentials, the user is sent back to the application’s
default page where he/she is greeted by a “Hello, [user name]” message.
At this stage, it is not possible to create another application, say the http://localhost/app2/ application and
have it use the login page we just built: by default, a given application cannot decrypt another’s data. We will
now examine how to alleviate this default constraint in the next two sections.
ASP.NET Single Form Authentication Sign-on 5
3/22/2005 © Philippe Lacoude
Encryption of Form Authentication Tickets
ASP.NET uses encryption keys to protect the confidentiality and integrity of the authentication tickets. The
<machineKey> element configures these keys3. This element can be declared at the machine, site, and
application levels, respectively in the machine.config, Web.config and app.exe.config files. The
machine.config file is located in the %WINDOWS%\Microsoft.NET\Framework\v1.1.4322\CONFIG folder. It is
located inside of the <system.web> element of the <configuration>.
<machineKey validationKey="AutoGenerate|value1[,IsolateApps]"
decryptionKey="AutoGenerate|value2[,IsolateApps]"
validation="SHA1|MD5|3DES" />
The validationKey is the key used to validate encrypted data. When enableViewStateMAC is true, ASP.NET
adds a signature4 to prevent tempering of the view state. The key is also used to create unique session IDs
that ensure that data cannot be shared between sessions.
By default, the .NET Framework uses the AutoGenerate keyword to force the Common Language Runtime
(CLR) to generate the ASP.NET key by itself. The key is stored in the Local Security Authority (LSA). This
creates trouble when the server is a node in a load-balanced server farm: one machine cannot validate the data
of another. This issue affects all versions of ASP.NET.
In ASP.NET 1.1, the phenomenon also happens between applications hosted of the same server because the
default settings use the new IsolateApps modifier. This keyword, which did not exist in ASP.NET 1.0, prevents
applications from being able to validate each other’s data. For each application, ASP.NET 1.1 stores one autogenerated
key in the LSA.
The decryptionKey settings have the same meaning. The IsolateApps keyword prevents some app1
application to share the cookie data of an app2 application.
Multiple Applications and Single Sign-On
The first solution to this problem is to remove the IsolateApps modifier from the machine.config file. This
allows applications to validate each other’s data. The action reverts ASP.NET 1.1 security to the settings of
ASP.NET 1.0. It is perfectly legitimate to do so if multiple applications must share a single sign-on.
If say, app1 and app2 must share a single sign-on page, but app3 should have its own user database and
therefore a different sign-on process, this poses a problem. Removing the IsolateApps modifier from the
machine.config file allows app1 and app2 to share the same Forms Authentication cookie but it also allows
app3 to decrypt it. The solution to this problem is very trivial: in the Web.config file, one specifies two
different cookie names in the <forms> section, one for app3 and another one for app1 and app2.5
3 These keys are also used to secure the view state data and to verify out-of-process session state identification.
4 The signature is also known as a “message authentication code” (MAC.)
5 Cf. the section “ASP.NET 1.0 Forms Authentication: A Third and Final Note of Caution”, page 12, for alternate solutions to this
problem.
ASP.NET Single Form Authentication Sign-on 6
3/22/2005 © Philippe Lacoude
If you do not have access to the machine.config file or if you host a large number of web sites and
applications on a single server and do not want to change your machine settings to accommodate just two
app1 and app2 applications, you can generate the two keys yourself.
In this case, you leave the machine.config file unchanged and you add a <machineKey> section to the
<system.web> element of the <configuration> of the Web.config files of each application. The new section
reads
<machineKey validationKey="value1" decryptionKey="value2" validation="SHA1|MD5|3DES" />
where:
• value1 specifies a manually assigned validation key. The key should be a hexadecimal string with a
length comprised between 40 characters (20 bytes) and 128 characters (64 bytes) long, the latter being
Microsoft’s recommended value.
• value2 specifies a manually assigned decryption key. The key length depends on the algorithm: when
using DES encryption, it should be 16 characters longs. For Triple DES (3DES), the key is 48
characters long6.
The new section must be identical between the two applications, or, in other words, you must use the same
validationKey and decryptionKey keys across all the applications that share the same forms authentication
cookie7.
If you use load balancing, you must change the <machineKey> section of the machine.config file: the two
keys (validationKey and decryptionKey) must be identical across all the servers in your web farm.
As a side note, let us add that you can enforce the IsolateApps option of ASP.NET 1.1 on your server: if, for
security reasons, you do not want to grant programmers the right to add a <machineKey> section in their
Web.config files, you can change the configSections element of the machine.config file. This ensures that
two applications will never be able to share data.
<section name="machineKey"
type="System.Web.Configuration.MachineKeyConfigHandler, System.Web, Version=1.0.5000.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" allowDefinition="MachineOnly" />
The allowDefinition attribute must be changed from "MachineToApplication" to "MachineOnly". It will
prevent Web.config or app.exe.config files from having a <machineKey> section.
Generating Custom Validation and Decryption Keys
If you set the validationKey and decryptionKey keys manually, you should generate them using the .NET
cryptographic library.
6 If you work for the Federal Government, or one of its contractors, and if your site hosts sensitive data, the key length must be 128
characters and you must use the 3DES (triple DES) algorithm for validation. Cf. the NIST FIPS 140-2 guideline.
7 Cf. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfmachinekeysection.asp for additional
details.
ASP.NET Single Form Authentication Sign-on 7
3/22/2005 © Philippe Lacoude
The process is relatively simple: using the System.Security.Cryptography namespace, simply call the
following function
private static string Key(int keyLength)
{
byte[] bytes = new byte[keyLength];
RNGCryptoServiceProvider randomNumGen = new RNGCryptoServiceProvider();
randomNumGen.GetBytes(bytes);
return Bytes2Hex(bytes);
}
where Bytes2Hex is an ad hoc helper function which converts a byte array into a hexadecimal string of
characters8. Assuming you build a .NET command-line utility called CryptoKeys to host the above method,
you then generate two keys of 24 and 64 bytes for the decryptionKey and validationKey keys:
You can then add the following section to your Web.config files:
<machineKey
validationKey="827E6556ABCF5360806E2169874479606C53A3C33E5DCD1E04DCF2BA09F4CE48D235CD9D00399EA3A3E6B
232F3BBA2C920962F0F61643C0F917A087D43F83BAC"
decryptionKey="1F4F7ED980232611C05F289A708886775A3D268378260F10" validation="3DES" />
All the applications that host these keys in the machineKey section of their Web.config files can now share the
same authentication cookie: you have built a single sign-on solution. The solution can even be hosted on
multiple servers behind Cisco, Nortel Networks or F5 BigIP load-balancing devices.
We can now create a second application on the local host, say the http://localhost/app2/ application. We
can use the login page of the http://localhost/app1/ application. All we have to do is to redirect
unauthenticated users to the login page:
<authentication mode="Forms">
<forms name=".ASPXAUTH" loginUrl="/app1/login.aspx" protection="All" timeout="30" path="/" />
</authentication>
<authorization>
<deny users="?"/>
</authorization>
The two applications can now work in concert. The user requests the default.aspx page of the app2
application , is redirected to the login.aspx page of the app1 application , logs in , and is finally sent to
the initially requested resource (Cf. Figure 1, next page.)
8 For a complete sample, refer to “Appendix C – Random Crypto-keys Generator”, page 17 or to Microsoft Knowledge Base article
312906, “How To: Create Keys by Using Visual C# .NET for Use in Forms Authentication”.
ASP.NET Single Form Authentication Sign-on 8
3/22/2005 © Philippe Lacoude
/app1
/app2
default.aspx
login.aspx
Web.config
default.aspx
Web.config
Figure 1
The only condition we still need to meet is that all the applications that share this single sign-on must be
hosted on the same domain. We will see how to work around this limitation, but we must first have a look at
how authentication cookies are really created.