Overview of How The Shibboleth Authentication Provider Works

Coordinator
Dec 9, 2010 at 6:51 PM
Edited Dec 9, 2010 at 6:53 PM

The code closely resembles the code for the Active Directory Provider for DotNetNuke because we used this code as a base and modified it to build the Shibboleth provider. A main difference between these 2 providers is that with Shibboleth, we have a login page that is used by the entire university for handling Shibboleth authentication which we must use. This is probably true as well for other institutions using Shibboleth authentication.

Like the DNN AD provider, this Shibboleth provider uses an AuthenticationModule.vb file with an OnAuthenticateRequest that that fires anytime DNN needs to authenticate a request. This authentication module controls the flow of processing and may transfer control to several different places, depending on the user’s request and status. If the user is requesting a login and Shibboleth is enabled, if the user has not yet been authenticated to Shibboleth during this session, control will be passed to ShibHandler.ashx so that user attributes can be extracted from the Shibboleth header.

ShibHandler.ashx is an HTTP handler that resides in the Login subdirectory which is a subdirectory protected by Shibboleth. The Login subdirectory is protected by Shibboleth by coding an entry in the Shibboleth2.xml file. Because this directory is protected, when a request is made to access this subdirectory, Shibboleth checks to see whether the user has been authenticated to Shibboleth, and if they have not, they are automatically transferred to the UF Login page where they enter their username and password. After successful authentication, Shibboleth transfers control to ShibHandler.ashx where processing continues to log the user into DNN. If the user has already been authenticated to Shibboleth, control will be transferred directly to the ShibHandler.ashx page without first going to the UF Login page.

The ProcessRequest routine in ShibHandler gets the user attributes returned by Shibboleth, loops through the group and role headers returned by Shibboleth, and assigns their values to public properties which are used later in code to update the user information.

Once the Shibboleth data has been retrieved, the code uses modified versions of the same routines that exist in the Active Directory provider to create the user if needed and to log the user into DNN. Whereas, the routine ManualLogon is called to log the user into DNN from the Login.ascx page of the Active Directory provider, the routine ManualLogin is called from ShibHandler to log the user into DNN from the Shibboleth provider.

The Shibboleth provider also has a control where the user can map those roles and groups that were returned by Shibboleth to existing DNN roles so that when the user authenticates, their roles are automatically synchronized to the existing DNN roles.

The Shibboleth provider also allows you to login to DNN without logging into Shibboleth in case you want to go in as ‘Host’ or ‘Admin’ without having to authenticate through Shibboleth.  Like the other DNN authentication providers, a Login.ascx control exists in the module directory which contains the userid and password fields for logging in. This Login.ascx control can be loaded as the AccountLogin module on a Login page that the user needs to create. The name of this Login page is specified in the Settings page of the Shibboleth provider.