Steps to install version 1.00.03, 1.00.04, 1.00.05, 1.00.06

1)      Using the host account, install the module: ShibInstall_01.00.06.zip file which you have downloaded.

2)      Using the admin account, add 3 new pages, “LoginPage”, “LogoutPage”, and “Role Mappings”.

The login and logout pages can be called anything you want.   These two pages must be made viewable by all users. The role mappings page should be made viewable only by Admins and can be added to the Admin menu.

3)      Go to Extensions, Shibboleth_Authentication to go into the module settings and enable Shibboleth, and select the Logout and Login pages from the corresponding dropdown lists.

4)      Add the Account Login module to the Login page. Add the Shibboleth Authentication module to the Role Mappings page.

5)      Update the web.config in two places:

If you are using IIS7 or higher:

  Under <Modules> add this line:

     <add name="Authentication" type="UF.Research.Authentication.Shibboleth.HttpModules.AuthenticationModule, UF.Research.Authentication.Shibboleth" preCondition="managedHandler" />

  Under <Handlers> add this line:

     <add name="Authentication" verb="*" path="*InvokeShibHandler.ashx" type="UF.Research.Authentication.Shibboleth.ShibHandler, UF.Research.Authentication.Shibboleth" preCondition="integratedMode" /

If you are still using IIS6:

 Under <httpModules> add this line:

      <add name="Authentication"   type="UF.Research.Authentication.Shibboleth.HttpModules.AuthenticationModule, UF.Research.Authentication.Shibboleth"/>

 Under   <httpHandlers> add this line:

<add verb="*" path="*InvokeShibHandler.ashx" type="UF.Research.Authentication.Shibboleth.ShibHandler, UF.Research.Authentication.Shibboleth" />

After making this change, do not login again until you have updated the Role Mappings page as described below.

 6)      The role mapping page maps incoming Shibboleth values to existing DNN values.   Here are some examples of Role mappings that we use: We map the value from the Shibboleth header variable “HTTP_EPPN” to the DNN “userName” and “Email” fields. We also map the value from “HTTP_givenName” to “FirstName” and we map the value from “HTTP_sn” to “LastName”.  

Role mappings can also be mapped. This is an example of a role mapping that we use: We define the role “GS_WEB_DEV” to DNN and then map the Shibboleth header variable “RES-GS-WEB-DEV” to this DNN role that we defined.

Shibboleth security roles come in lists of strings separated by a delimiter. Each list of roles also has a Shibboleth header variable name. The first grid on the Role Mappings page contains the Shibboleth Header variable names for those header variables that contain role lists.

Another value that is input on the Role Mappings page is the Shibboleth UserName Variable which will be mapped to the DNN username. We use the variable “HTTP_EPPN” since this contains the user email address and is unique.

Here are the instructions for entering data in the Role Mappings page:

Go to the “Role Mappings” page (you should still be logged in as Admin), and add enter the Shibboleth UserName variable.

Be sure to click the “Update Shibboleth UserName ” button to save the username variable that you have just entered.

Then, in the first grid on the page, enter Shibboleth header variable names for your Shibboleth header variables that contain role mappings.

Be sure to click the “Update Shibboleth Header Variable ” button to save the header variable for role mappings that you have just entered into the grid.

In the second grid on the screen, enter the actual role mappings. You need to have already entered your DNN roles before inputting role mappings, since you will be specifying the Shibboleth roles that are mapped to the existing DNN roles. When you add a role mapping in the second grid, you will first select the existing DNN role. Then you will select the Shibboleth header variable from the dropdown list named “Shib Role Type” that contains the Shibboleth role that you are mapping. These Shibboleth Role Types are values that you entered into the first grid. Then you enter the Shibboleth Role Name.

Be sure to click the “Update User Role Mappings” button to save the role mappings that you have just entered into the grid.

Then in the third grid, enter user attributes at least for “Display Name”, “First Name”, “Last Name”, “Email” and “UserName”. You can also add more User attributes for any user profile properties that exist in DNN. In the third grid, the Overwrite flag is used to indicate whether existing values are overwritten or not. If checked, existing data will be overwritten. Otherwise, existing data will not be overwritten.

 

Be sure to click the “Update User Attributes” button to save the user attribute mappings that you have just entered into the grid.

 7)      The next step is to configure the Shibboleth2.xml file to secure the "~/DesktopModules/AuthenticationServices/Shibboleth/Login" directory to Shibboleth. When this directory is secured, when the provider attempts to access the http handler in this directory, Shibboleth will kick in and require you to authenticate before proceeding. Shibboleth uses its own login page which is unique for your institution. This login page will display fields for you to enter a username and password, and then control will be returned to DNN along with the Shibboleth server variables containing attributes unique to your login. These attributes will then be mapped to your DNN user account according to the role mappings and user attribute mappings that you have setup.

Here's an
example of the code we used in Shibboleth2.xml when testing on domain dnn1.research.ufl.edu:

<Host name="dnn1.research.ufl.edu:9999" applicationId="urn:edu:ufl:alpha1:99999" >

<Path name="DesktopModules" authType="shibboleth" requireSession="false">

   <Path name="AuthenticationServices" authType="shibboleth" requireSession="false">

     <Path name="Shibboleth" authType="shibboleth" requireSession="false">

       <Path name="Login" authType="shibboleth" requireSession="true">

       </Path>

     </Path>

   </Path>

</Path>

 After following these steps you should be ready to sign in to Shibboleth when you logout and then click the Login link in your DNN site.

 If you are doing an actual Shibboleth installation, at this point you have finished the installation. Steps 8 and 9 below are for running Shibboleth simulations.

8)      With this version of the Shibboleth provider, we have also included the ability to simulate a Shibboleth login so that the provider can be accessed and tested without actually having access to Shibboleth. There is a checkbox in the configuration settings to Simulate Shibboleth and if this box is checked, Shibboleth simulation test “server variables” will be retrieved from text files rather than from Shibboleth. There are 2 *.txt files included with this package for these test server variables.  Instead of doing step #7 above to configure the Shibboleth2.xml file, you can view and modify the text files to add your own test server variables. The 2 text files that we use are TestCase.txt and TestCaseWarrenResearch.txt. TestCase.txt only contains a single entry which is the name of the text file containing the test server variables: “TestCaseWarrenResearch.txt” . You can create more text files and test them by changing the text name of the file contained in TestCase.txt

 If you open TestCaseWarrenResearch.txt you will see this data:

 UFAD_Groups:RES-GS-WEB-DEV;RES-IS-DEVELOPERS-USERS;RES-IS-SQLADMINS;RES_LAPTOP_OWNERS;RES_SHARE-SOFTWARE

UFAD_PSRoles:UF_HR_EMPLOYEE$UF_GL_FISCAL_FUNCTIONS$UF_EX_TRAVELER$UF_HR_EMPLOYEE$UF_N_MKT_SHOPPER$UF_PY_EMPLOYEE

HTTP_EPPN:net-services@research.ufl.edu

HTTP_LNAME:Resaearch

HTTP_GLID:22222222

HTTP_businessName:Warren G. Research

HTTP_displayName:Resaearch, Warren G.

HTTP_givenName:Warren

HTTP_SN:Research

 The first line of text shows values for Shibboleth variables of type “UFAD_Groups”. These values will be mapped to DNN roles according to the Role Mappings that you have setup. The individual groups are separated by semicolons and follow the header variable “UFAD_Groups”. The header variable is separated from the groups contained in this header variable by a colon.

 The second line of text shows values for Shibboleth variables of type “UFAD_PSRoles”. These values will also be mapped to DNN roles according to the Role Mappings that you have setup. The individual groups are separated by a dollar sign and follow the header variable “UFAD_PSRoles” followed by “:”.

You will need to update your Role Mappings page like this:

Under Shibboleth UserName variable, enter: “HTTP_EPPN”. Be sure to click the update button to save your changes.

In the first grid for Shibboleth Header Variables, add 2 header variable names and the delimiters for each of these: “UFAD_Groups” is the header variable name and “;” is the delimiter.   For the second entry enter “UFAD_PSRoles” as the header variable name and “$” as the delimiter.   Be sure to click the update button to save your changes.

In the second grid, enter some role mappings. For example, you could define the following role to DNN: GS_Web_Dev. Then in the second grid you could select this role for DNN Role Name, then select “UFAD_Groups” as the Shibboleth Role type, and then select “RES-GS-WEB-DEV” as the Shib Role name. Be sure to click the update button to save your changes.

In the third grid, enter values for user attributes. For example, you can select a User Property type of “User”, select a DNN property of “Display Name”, and select a Shibboleth source of “HTTP_displayName” to map the HTTP_displayName field to the DNN Display Name. Be sure to click the update button to save your changes.

The text in lines 3-9 display a server variable, followed by a colon, followed by the value of the server variable.  

 When simulating shibboleth and using the TestCaseWarrenResearch.txt file, a DNN user with username, net-services@research.ufl.edu will be created in DNN if you have set up a user attribute mapping with “HTTP_EPPN” mapped to DNN “userName” and you have specified “HTTP_EPPN” as your Shibboleth UserName variable. The user’s display name will be “Research, Warren G.” if you have a user attribute mapping setup with the HTTP_displayName server variable mapped to the DNN display name. The HTTP_GLID, HTTP_businessName, HTTP_givenName, and HTTP_SN variables will also be mapped to corresponding DNN variables where user attribute mappings have been setup.
Likewise, “UFAD_Group” roles will be mapped to DNN roles that you have defined to DNN and have setup a role mapping for. The same is true for “UFAD_PSRoles”.

 To test different sets of data, just create more *.txt files and specify the text file names, one at a time in the txt file “TestCase.txt”.

 9)      If you are simulating Shibboleth, you will need to go back to the module settings and check the “Simulate Login” button to start the simulation. After checking this button, you can click the Logout button to logout of the admin account, and then click the Login button again to login as the user in the files specified in the TestCase.txt file. Until you change the information in the *.txt files, you will be logging in as Research, Warren G.

 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Steps to install version 1.00.02

1)      Using the host account, install the module: “ShibInstall.zip” which is located under Downloads.

2)      Using the admin account, add 3 new pages, “Login”, “Logout”, and “Role Mappings”.

The login and logout pages can be called anything you want.   These two pages should be made viewable by all users. The role mappings page should be made viewable only by Admins and can be added to the Admin menu.

3)      Go to Extensions, Shibboleth_Authentication to go into the module settings and enable Shibboleth, and select the Login and Logout pages from the corresponding dropdown lists.

4)      Add the Account Login module to the Login page. Add the Shibboleth Authentication module to the Role Mappings page.

5)      Update the web.config in two places:

 Under <httpModules> add this line:

      <add name="Authentication"   type="UF.Research.Authentication.Shibboleth.HttpModules.AuthenticationModule, UF.Research.Authentication.Shibboleth"/>

 Under   <httpHandlers> add this line:

<add verb="*" path="*InvokeShibHandler.ashx" type="UF.Research.Authentication.Shibboleth.ShibHandler, UF.Research.Authentication.Shibboleth" />

 6)      The role mapping page maps incoming Shibboleth values to existing DNN values.   Here are some examples of Role mappings that we use: We map the value from the Shibboleth header variable “HTTP_EPPN” to the DNN “userName” and “Email” fields. We also map the value from “HTTP_givenName” to “FirstName” and we map the value from “HTTP_sn” to “LastName”.  

Role mappings can also be mapped. This is an example of a role mapping that we use:We define the role “GS_WEB_DEV” to DNN and then map the Shibboleth header variable “RES-GS-WEB-DEV” to this DNN role that we defined.

Go to the “Role Mappings” page (you should still be logged in as Admin), and add user attributes at least for “Display Name”, “First Name”, “Last Name”, and “Email”. You can also add more User attributes for any user profile properties that exist in DNN.

Be sure to click the “Update User Attributes” button to save the user attribute mappings that you have just entered into the grid.

 Then define a role to DNN and map an incoming Shibboleth role to this DNN role.

Be sure to click the “Update User Role Mappings” button to save the role mappings that you have just entered into the grid.

On the Role Mappings page, the Overwrite flag is used to indicate whether existing values are overwritten or not. If checked, existing data will be overwritten. Otherwise, existing data will not be overwritten.

7)      The next step is to configure the Shibboleth2.xml file to secure the "~/DesktopModules/AuthenticationServices/Shibboleth/Login" directory to Shibboleth. When this directory is secured, when the provider attempts to access the http handler in this directory, Shibboleth will kick in and require you to authenticate before proceeding. Shibboleth uses its own login page which is unique for your institution. This login page will display fields for you to enter a username and password, and then control will be returned to DNN along with the Shibboleth server variables containing attributes unique to your login. These attributes will then be mapped to your DNN user account according to the role mappings and user attribute mappings that you have setup.

Here's an
example of the code we used in Shibboleth2.xml when testing on domain dnn1.research.ufl.edu:

<Host name="dnn1.research.ufl.edu:9999" applicationId="urn:edu:ufl:alpha1:99999" >

<Path name="DesktopModules" authType="shibboleth" requireSession="false">

   <Path name="AuthenticationServices" authType="shibboleth" requireSession="false">

     <Path name="Shibboleth" authType="shibboleth" requireSession="false">

       <Path name="Login" authType="shibboleth" requireSession="true">

       </Path>

     </Path>

   </Path>

</Path>

 After following these steps you should be required to sign in to Shibboleth when you logout and then click the Login link in your DNN site.

 If you are doing an actual Shibboleth installation, at this point you have finished the installation. Steps 8 and 9 below are for running Shibboleth simulations.

 

8)      With this version of the Shibboleth provider, we have also included the ability to simulate a Shibboleth login so that the provider can be accessed and tested without actually having access to Shibboleth. There is a checkbox in the configuration settings to Simulate Shibboleth and if this box is checked, Shibboleth simulation test “server variables” will be retrieved from text files rather than from Shibboleth. There are 2 *.txt files included with this package for these test server variables.  Instead of doing step #7 above to configure the Shibboleth2.xml file, you can view and modify the text files to add your own test server variables. The 2 text files that we use are TestCase.txt and TestCaseWarrenResearch.txt. TestCase.txt only contains a single entry which is the name of the text file containing the test server variables: “TestCaseWarrenResearch.txt” . You can create more text files and test them by changing the name of the file contained in TestCase.txt

 If you open TestCaseWarrenResearch.txt you will see this data:

 UFAD_Groups:RES-GS-WEB-DEV;RES-IS-DEVELOPERS-USERS;RES-IS-SQLADMINS;RES_LAPTOP_OWNERS;RES_SHARE-SOFTWARE

UFAD_PSRoles:UF_HR_EMPLOYEE$UF_GL_FISCAL_FUNCTIONS$UF_EX_TRAVELER$UF_HR_EMPLOYEE$UF_N_MKT_SHOPPER$UF_PY_EMPLOYEE

HTTP_EPPN:net-services@research.ufl.edu

HTTP_LNAME:Resaearch

HTTP_GLID:22222222

HTTP_businessName:Warren G. Research

HTTP_displayName:Resaearch, Warren G.

HTTP_givenName:Warren

HTTP_SN:Research

 The first line of text shows values for Shibboleth variables of type “UFAD_Groups”. These values will be mapped to DNN roles according to the Role Mappings that you have setup. The individual groups are separated by commas and follow the header variable “UFAD_Groups”. The header variable is separated from the groups contained in this header variable by a colon.

 The second line of text shows values for Shibboleth variables of type “UFAD_PSRoles”. These values will also be mapped to DNN roles according to the Role Mappings that you have setup. The individual groups are separated by commas, and follow the header variable “UFAD_PSRoles” followed by “:”.

 The text in lines 3-9 display a server variable, followed by a colon, followed by the value of the server variable.  

 When simulating shibboleth and using the TestCaseWarrenResearch.txt file, a DNN user with username, net-services@research.ufl.edu will be created in DNN if you have set up a user attribute mapping with “HTTP_EPPN” mapped to DNN “userName”. The user’s display name will be “Research, Warren G.” if you have a user attribute mapping setup with the HTTP_displayName server variable mapped to the DNN display name. The HTTP_GLID, HTTP_businessName, HTTP_givenName, and HTTP_SN variables will also be mapped to corresponding DNN variables where user attribute mappings have been setup.
Likewise, “UFAD_Group” roles will be mapped to DNN roles that you have defined to DNN and have setup a role mapping for. The same is true for “UFAD_PsRoles”.

 To test different sets of data, just create more txt files and specify the text file names, one at a time in the txt file “TestCase.txt”.

 9)      If you are simulating Shibboleth, you will need to go back to the module settings and check the “Simulate Login” button to start the simulation. After checking this button, you can click the Logout button to logout of the admin account, and then click the Login button again to login as the user in the files specified in the TestCase.txt file. Until you change the information in the *.txt files, you will be logging in as Research, Warren G.

-------------------------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------------------------

Steps to install version 1.0.1 

1. Install the module: "ShibInstall.zip" which is located under Downloads .

2. Using the admin account, add 3 new pages: a login page, a logout page, and a role mappings page.
The login and logout pages can be called anything you want.
These two pages should be viewed by all users. On the login page add the module: Account Login.

Add a role mapping page. This must be named "RoleMappings.aspx" and should only be viewable by admins.
On the role mapping page, add the module: Shibboleth_Authentication. This will be the Radgrid
where administrators can map shibboleth roles to existing dnn roles.

3. Go into the settings module and enable shibboleth and select your new login and logout pages from the
dropdown lists.

If at anytime during the initial configuration, you need to get back to the original DNN login screen,
and you forgot to setup your login page, you can make your shibboleth signon a superuser and then
add the pages as usual.

4. Modify your web config:

Add this line to the <httpModules> </httpModules> section of the web.config:

<add name="Authentication" type="UF.Research.Authentication.Shibboleth.HttpModules.AuthenticationModule, UF.Research.Authentication.Shibboleth"/>

5. Secure your "~/DesktopModules/AuthenticationServices/Shibboleth/Login" directory to Shibboleth in the Shibboleth.xml file. Here's an
example of the code we used when testing on domain dnn1.research.ufl.edu:

<Host name="dnn1.research.ufl.edu:9999" applicationId="urn:edu:ufl:alpha1:99999" >

<Path name="DesktopModules" authType="shibboleth" requireSession="false">

<Path name="AuthenticationServices" authType="shibboleth" requireSession="false">

<Path name="Shibboleth" authType="shibboleth" requireSession="false">

<Path name="Login" authType="shibboleth" requireSession="true">

</Path>

</Path>

</Path>

</Path>

</Host>

Last edited Oct 15, 2011 at 12:18 PM by cbearden, version 14

Comments

No comments yet.