For the last few weeks, I have been working on a couple of enhancements for 4.6.0.
- Alternate Authentication Systems
- A new Extensible Installer for components
This blog will introduce the first of these features, a future blog will cover the new Installer.
Over the last few months a number of new Authentication Systems have been introduced (or announced). These include, for example, Cardspace (introduced as part of .NET 3.0), OpenID and LiveID (the Windows Live replacement of Passport). DotNetNuke has supported alternate authentication systems since 3.x when the the Windows (or ACtive Directory) provider was introduced. Unfortunately, this provider approach does not lend itself for use with these new authentication systems. We have therefore decided to overhaul the "Authentication provider" approach used and provide new "providers" for Cardspace, OpenID and LiveID.
While we call the new Authentication Systems - "Providers" they are not providers in the sense that they follow the same provider pattern as used in the othe providers in DotNetNuke. The main reason for this, is that the Authentication providers need to implement three UI components - Login, Settings and LogOff. These are registered in the new Authentication Table (see below)
This table is fairly straightforward with columns for the Authntication type, an IsEnabled flag, and three columns for the control src for the Login. Settings and LogOff controls. (The Business Layer in the core Frameowork provides a similar AuthenticationInfo class and AuthenticationController, as well as base classes for each of the Controls (AuthenticationLoginBase, AuthenticationSettingsBase and AuthenticationLogOffBase).
The image to the left shows the Login Control when 3 Login Providers are enabled - in this case the standard DNN provider, LiveID and OpenID. The Image to the right shows the new Authentication Admin page (with 4 Login Providers enabled)
Both of these images illustrate the procedure used by these "providers". The original controls (SignIn.ascx and Authentication.ascx) have been replaced by new container controls that inject the relevant subcontrols. In the case of the Settings control, a settings control (that inherits for AuthenticationSettingsBase) is injected for any provider that is enabled in the Authentication table (DNN, Cardspace, LiveID and OpenID). The settings are all persisted in the Module Settings for the Authentication Module - each provider using a unique Prefix for its settings. In the example shown the Cardspace module is not enabled for this portal, and this is why the Login control only injects subcontrols for three of the providers.
So, How does the login work. We will use the example of the OpenID Login.
I entered my OpenID ID (http://cnurse.myopenid.com). When I click the "Login with OpenID" button I am redirected to the myopenid site to login to my OpenID account.
If the OpenID ID has been associated with a DotNetNuke account, when you sign in to your OpenID provider you will be redirected back to DotNetNuke and logged in. The actual procedure is that the OpenID subcontrol calls a new method of UserController that checks if the OpenID token is associated with a UserID. If it is, it fires a "UserAuthenticated" event passing the DotNetNuke user as a property of the EventArgs and the Parent control completes the log in and redirects the user to the appropriate page.
The associations are stored in a new table UserAuthentication.
So in this case the OpenID token is mapped to UserID=11, and I am logged in.
What happens if my alternate Authentication ID is not already associated with a DNN account?
I entered a different OpenID ID (http://claimid.com/cnurse). When I click the "Login with OpenID" button I am redirected to the claimid site to login to my OpenID account.
This time, when I click login, as this openID is not associated with a DotNetNuke account, the OpenID subcontrol fires the UserAuthenticated event but does not pass a user, so the parent control presents the user with a "Register/Associate" page.
The top section of this page indicates the type of Authentication used and the Identity (User Token) used. It then provides the user with two options.
- Associate this ID with an existing Account - by entering the UserID/Password
- Register (Create) a new DotNetNuke Account.
The figure above denonstrates another feature of some of the alternate authentication systems (Cardspace, OpenID) - the Registration fields are pre-populated from Profile Information passed by the Authentication Provider.
There is much more to the Authentication Providers than this Blog can describe, but hopefuly you get the idea of how this works.