SharePoint FBA: SSL Required

Recent changes in Chrome to improve cookie security required flags being set on the cookies in order for them to continue to function cross-domain. Microsoft released patches to SharePoint to implement the flags – however the flags also require the cookie to be marked SECURE and now only allows the cookies to function with HTTPS/SSL. Granted you should only be using FBA in production with SSL, however it was convenient to not use it in dev/test environments. So if you think you have FBA setup correctly, but aren’t able to login – this is most likely the problem. Setup the site to use SSL and it should start working.

If you have both windows authentication and forms authentication enabled on the same site, and choose to authenticate with windows authentication – even that will no longer work without SSL enabled. You’ll get a “Sorry, Something Went Wrong” – “An unexpected error has occurred.” error.

SQL Server Spatial Data: Finding and Ordering Distance Between 2 Points

It’s pretty common to want to find the distance from a certain location to a location stored in your database. For example, in the Home Depot or Walmart website you might want to find the closest store. The locations of all of the stores will be stored in a database, and then given your location the distance to each store can be calculated and ordered by the closest stores.

The following example SQL Server queries shows you how to do just that:


--Create the table. Use the 'geography' data type to store spatial data
CREATE TABLE [dbo].[places](
[address] [varchar](max) NULL,
[coords] [geography] NULL
)

--Add locations to the table. You use the geography::Point notation to enter set the latitude/longitude for the location.
insert into places (address, coords)
values ('Shell - 4685 Central Pkwy E Mississauga, ON L4Z 2E4',geography::Point(43.616597, -79.641492,4326))

insert into places (address, coords)
values ('Mcdonalds - 44 Bristol Rd E, Mississauga, ON L4Z 3K8',geography::Point(43.614680, -79.660373,4326))

insert into places (address, coords)
values ('Tim Hortons - 3 Robert Speck Pkwy, Mississauga, ON L4Z 2G5',geography::Point(43.598257, -79.636555,4326))

--Set a variable equal to the point to search from, also by specifying the latitude/longitude
DECLARE @mylocation geography = geography::Point(43.616600, -79.638489,4326)

--Query, calculating the distance from @mylocation to each point using the STDistance function of the geography datatype. Order the results by that calculated distance
SELECT TOP(7) *, coords.STDistance(@mylocation) distanceinmeters FROM places
ORDER BY coords.STDistance(@mylocation);

A few notes:

The number 4326 is used several times in the queries. This specifies the coordinate system to use. 4326 refers to WGS84 which is the common standard used: https://en.wikipedia.org/wiki/World_Geodetic_System. Distance calculation results will be in meters.

To get the latitude/longitude of locations to store in your database, it is probably easiest to get them from Google Maps. Simply right-click the location you would like to get the values for, and select ‘What’s here?’ from the popup menu. The latitude and longitude of the location will be displayed.

To get the latitude/longitude of the From point, you can use the Geolocation API from the browser: https://developer.mozilla.org/en-US/docs/Web/API/Geolocation_API. Alternatively you can convert an address or postal code to a latitude/longitude using a geocoding api, like the Google Maps geocoding api: https://developers.google.com/maps/documentation/geocoding/intro

Now Hosting Inline Styler for Emails

We’ve been using this great inline styler for email’s created by @davecranwell (originally hosted at http://inlinestyler.torchbox.com).  Unfortunately it’s been offline for about a month, so today I setup hosting for it.  It can now be found at: https://inlinestyler.visigo.com/.

What it does is take HTML + CSS and moves the css styles inline in the html.  This is used for formatting html emails, as css styles aren’t supported by email clients.

Forked github repo can be found here:  https://github.com/Visigo/inline-styler.

SharePoint 2016 compatible version of the SharePoint Solution Installer released

I’ve updated the SharePoint Solution Installer to be compatible with SharePoint 2016.

Release can be downloaded here:

https://github.com/Visigo/sharepointinstaller/releases/tag/SharePointInstaller-SP2013-V1.5.0

Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 – Part 4 – Adding Users to the Membership Database

Configuring forms based authentication (FBA) in SharePoint 2016 and SharePoint 2019 is exactly the same process as configuring it for SharePoint 2013.  I’ve recreated the SharePoint 2013 FBA tutorial specifically for SharePoint 2016 and SharePoint 2019, using screenshots from SharePoint 2016 and Windows Server 2012 R2.  I have changed the tutorial to use the SharePoint FBA Pack to create the FBA users, but otherwise it remains the same and can be used interchangeably between SharePoint 2013 and SharePoint 2016/2019.

I’ll go through all of the steps required to setup FBA for SharePoint 2016 and 2019, from start to finish.  I’ve broken down the steps into 4 sections, so if you already have an existing membership database setup from a previous version of SharePoint, feel free to skip forward to Part 2.

Part 1 – Creating the Membership Database

Part 2 – Editing the Web.Config Files

Part 3 –  Configuring SharePoint

Part 4 – Adding Users to the Membership Database

You can also watch a video of the whole process on YouTube: Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019.

Part 4 – Adding Users to the Membership Database

At this point SharePoint has been completely been setup for forms based authentication. Unfortunately people still can’t login with FBA, as no users have been added to the membership database.

There are a few ways to add users to the membership database.  You can manage the users in the membership database using IIS. I prefer to manage the users in SharePoint using the SharePoint FBA Pack. I’m going to show you how to install the FBA Pack and use it to add users to your membership database.

  • You can find downloads and documentation for the SharePoint 2016 FBA Pack at https://www.visigo.com/products/sharepoint-fba-pack.
  • Download the FBA Pack and unzip it to a folder on your hard drive. For this example I’ve unzipped to c:\deploy.deploy folder
  • Open either PowerShell (In Administrator mode) or SharePoint Management Shell.
  • Navigate to the c:\deploy folder: “cd c:\deploy”Powershell
  • Run “.\deploy http:\\win-h472cerv00l” (without quotes and be sure to substitute the url to your site collection where you would like the FBA Pack activated).  Note you can also run “.\deploy” without any parameters – in which case you will have to manually activate the “Forms Based Authentication Management” feature in each site collection you’d like to use it.Deploy FBA Pack
  • The script will deploy the FBA Pack to the SharePoint farm and activate it on your site collection. Note that if you get an error and scripts won’t run because they are not signed, you need to run the following command to allow the script to run: “Set-ExecutionPolicy Unrestricted”. Once you’ve done that, rerun the deploy script.
  • Navigate to your site collection and login as a site collection administrator. Navigate to the Site Settings page. You will notice you now have some new options for managing FBA Users.SharePoint 2016 Site Settings
  • Select “FBA User Management”.SharePoint 2016 FBA Pack Manage Users
  • Click “New User”.SharePoint 2016 FBA Pack New User
  • Fill out the form to create your first user in the FBA database. Be sure to assign them to a SharePoint group so that they will have permissions to login to SharePoint.
  • Now you can try to login as the user you just created. Logout of SharePoint. When logging back into SharePoint, choose to login using Forms Based Authentication. Login using the username and password you created on the FBA User Management screen.SharePoint 2016 FBA Login

That’s it!  You now have Forms Based Authentication setup on SharePoint 2016, and the FBA Pack installed to manage your FBA users.  Be sure to check out the rest of the features of the SharePoint FBA Pack – on top of allowing you to manage users and roles, it also includes web parts for user registration, changing your password and recovering a forgotten password.

Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 – Part 3 – Configuring SharePoint

Configuring forms based authentication (FBA) in SharePoint 2016 and SharePoint 2019 is exactly the same process as configuring it for SharePoint 2013.  I’ve recreated the SharePoint 2013 FBA tutorial specifically for SharePoint 2016 and SharePoint 2019, using screenshots from SharePoint 2016 and Windows Server 2012 R2.  I have changed the tutorial to use the SharePoint FBA Pack to create the FBA users, but otherwise it remains the same and can be used interchangeably between SharePoint 2013 and SharePoint 2016/2019.

I’ll go through all of the steps required to setup FBA for SharePoint 2016 and 2019, from start to finish.  I’ve broken down the steps into 4 sections, so if you already have an existing membership database setup from a previous version of SharePoint, feel free to skip forward to Part 2.

Part 1 – Creating the Membership Database

Part 2 – Editing the Web.Config Files

Part 3 –  Configuring SharePoint

Part 4 – Adding Users to the Membership Database

You can also watch a video of the whole process on YouTube: Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019.

Part 3 –  Configuring SharePoint

Now that the membership and role provider have been configured, we can configure SharePoint to use them.  For this example i’m going to edit an existing web application to use forms based authentication. The same settings can be applied when creating a new web application.

  • Open SharePoint Central Administration -> Application Management -> Manage Web Applications.
  • Select the web application you’d like to edit and click “Authentication providers”.sharepoint web application authentication providers
  • Select the zone of the authentication provider you’d like to edit. In this case I only have a single zone setup: “Default”.  If you like, you can add multiple zones by extending the web application.  This will allow you to select different forms of authentication to the same web application depending on the url used to access it.  For example if users hit the web application using the local server name, then it can authenticate them with windows authentication.  If they access it via an external domain name, you could have it authenticate them with FBA. authentication provider zone
  • Check “Enable Forms Based Authentication (FBA)”. Enter the ASP.Net Membership Provider Name and ASP.NET Role Provider Name that you configured in the web.config. For this example we used “FBAMembershipProvider” and “FBARoleProvider” (Without the quotation marks). In this case we left “Enable Windows Authentication” checked. This allows us to login either via Windows Authentication or Forms Based Authentication (SharePoint will prompt you when you login for which method you’d like to use).Click “Save”.Authentication Provider Setup
  • Now when authenticating to the site collection, if you enabled both Windows Authentication and Forms Based Authentication, you’ll be prompted for which method you’d like to use to authenticate. SharePoint select login type

At this time however, you still cannot authenticate with forms based authentication, as we haven’t created any users in the membership database.  In Part 4 i’ll show you how to use the FBA Pack to add users to the membership database.

Important – Additional Steps for enabling FBA for Office Applications

Thank you to Denis Molodtsov for noticing that even with FBA configured in SharePoint 2016, it still won’t authenticate properly when opening a document from SharePoint with Office 2016 (Word, Excel, PowerPoint…).  Office 2016 now uses “Modern Authentication” by default – which does not support Claims authentication.  SharePoint 2016 releases from the June 2016 CU and onward allow Modern Authentication to be turned off.  To turn it off run the following in the SharePoint Management Shell:

$sts = Get-SPSecurityTokenServiceConfig
$sts.SuppressModernAuthForOfficeClients = $True
$sts.update()
iisreset

 

Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 – Part 2 – Editing the Web.Config Files

Configuring forms based authentication (FBA) in SharePoint 2016 and SharePoint 2019 is exactly the same process as configuring it for SharePoint 2013.  I’ve recreated the SharePoint 2013 FBA tutorial specifically for SharePoint 2016 and SharePoint 2019, using screenshots from SharePoint 2016 and Windows Server 2012 R2.  I have changed the tutorial to use the SharePoint FBA Pack to create the FBA users, but otherwise it remains the same and can be used interchangeably between SharePoint 2013 and SharePoint 2016/2019.

I’ll go through all of the steps required to setup FBA for SharePoint 2016 and 2019, from start to finish.  I’ve broken down the steps into 4 sections, so if you already have an existing membership database setup from a previous version of SharePoint, feel free to skip forward to Part 2.

Part 1 – Creating the Membership Database

Part 2 – Editing the Web.Config Files

Part 3 –  Configuring SharePoint

Part 4 – Adding Users to the Membership Database

You can also watch a video of the whole process on YouTube: Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019.

Part 2 – Editing the Web.Config Files

The next thing that has to be done to get forms based authentication working with SharePoint is setting up the membership provider.  A membership provider is an interface from the program to the credential store.  This allows the same program to work against many different methods of storing credentials. For example you could use an LDAPMembershipProvider to authenticate against Active Directory, or a SQLMembershipProvider to authenticate against a SQL Server database. For this example we’re using the SQLMembershipProvider to authenticate against a SQL Server database.

SharePoint is actually divided up into several web applications – Central Administration, the Security Token Service and all of the SharePoint web applications that you create. Each of those web applications needs to know about the membership provider. Most tutorials have you adding the membership provider settings over and over again in each web config (as well as every time you setup a new SharePoint web application).  I prefer to add the membership provider settings directly to the machine.config. By adding it to the machine.config, the configuration is inherited by all of the web.config files on the machine – so you only have to make the changes once, and don’t have to remember to make the changes every time you create a new SharePoint web application.

If you don’t have access to the machine.config, or prefer not to edit it, you will have to make all of these changes to the following web.config files:

  • SharePoint Central Administration
  • SecurityTokenServiceApplication
  • Every SharePoint web application you create that you would like to access via FBA.

NOTE – IF YOU HAVE MULTIPLE SERVERS, THESE STEPS MUST BE PERFORMED ON ALL SERVERS.

BEFORE EDITING ANY .CONFIG FILE – MAKE A BACKUP OF IT. It’s very easy to make a typo.

  • Navigate to “C:\Windows\Microsoft.Net\Framework64\v4.0.30319\Config” and open “machine.config”.sharepoint_2013_fba_config_1
  • In the <ConnectionString> section, add the following line:
    <add connectionString="Server=win-h472cerv001;Database=aspnetdb;Integrated Security=true" name="FBADB" />

    Be sure to replace the value for Server with the name of your SQL Server.machine config connection string

  • In the <membership><providers> section add the following:
    <add name="FBAMembershipProvider"
     type="System.Web.Security.SqlMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
     connectionStringName="FBADB"
     enablePasswordRetrieval="false"
     enablePasswordReset="true"
     requiresQuestionAndAnswer="false"
     applicationName="/"
     requiresUniqueEmail="true"
     passwordFormat="Hashed"
     maxInvalidPasswordAttempts="5"
     minRequiredPasswordLength="7"
     minRequiredNonalphanumericCharacters="1"
     passwordAttemptWindow="10"
     passwordStrengthRegularExpression="" />

    You can customize the authentication by modifying each of these options. The most important thing to remember though is that if you define a membership provider in multiple locations for the same database, they MUST ALL USE THE SAME OPTIONS. Otherwise you’ll run into all kinds of problems with users created with one set of options, and later being authenticated against with a different set of options.

    Here’s a description of the different options available:

    Option Description
    connectionStringName The name of the database connection to the aspnetdb database.
    enablePasswordRetrieval true/false. Whether the user’s password can be retrieved. I suggest setting this to false for security purposes.
    enablePasswordReset true/false. Whether the user can reset their password. I suggest setting this to true.
    requiresQuestionAndAnswer true/false. Whether accounts also have a question and answer associated with them. The answer must be provided when resetting the password. I suggest setting this to false, as setting it to true prevents an administrator from resetting the user’s password.
    applicationName Setting the application name allows you to share a single membership database with multiple different applications, with each having their own distinct set of users. The default applicationName is /.
    requiresUniqueEmail true/false. Determines if multiple users can share the same email address. I suggest setting this to false, in case you ever want to implement a login by email system.
    passwordFormat Clear, Hashed or Encrypted. Clear stores the password in the database as plain text, so anybody with access to the database can read the user’s password. Encrypted encrypts the user’s password, so although the password isn’t human readable in the database, it can still be decrypted and the user’s actual password retrieved. Hashed stores a one way hash of the password.  When a user authenticates, the password they enter is hashed as well and matched against the stored hashed value. Using this method, the user’s password can never be retrieved (even if your database is stolen), only reset.  I always recommend using “Hashed” as it is the most secure way of storing the user’s password.
    maxInvalidPasswordAttempts The number of times in a row that a user can enter an invalid password, within the passwordAttemptWindow, before the user’s account is locked out. Defaults to 5.
    passwordAttemptWindow The number of minutes before the invalid password counter is reset. Defaults to 10.
    minRequiredPasswordLength The minimum password length. Defaults to 7.
    minRequiredNonalphanumericCharacters The minimum number of non-alphanumeric characters required in the password. Defaults to 1.
    passwordStrengthRegularExpression A regular expression that can be used to validate the complexity of the password.

    sharepoint_2013_fba_config_3

  • In the <roleManager><providers> section add the following:
    <add name="FBARoleProvider" connectionStringName="FBADB" applicationName="/"
     type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

    Save and close the machine.config file.
    sharepoint_2013_fba_config_3_1

  • I mentioned that if you modified the machine.config, you’d only have to put the config in a single place.  I wasn’t being completely truthful.  The SharePoint Web Services configuration overrides the machine.config and clears the entries we created. For that reason, the membership and role providers also need to be added to the SecurityTokenService (But only there – you won’t have to add them to the central admin or other SharePoint web app web.configs.First we need to find the web.config for the SecurityTokenService. Open up IIS. Under sites, SharePoint Web Services, right click on SecurityTokenServiceApplication and click on Explore. Edit the web.config in the folder that opens.SharePoint Security Token Service
  • Add the following to the web.config, just before the closing </configuration> tag:
    <system.web>
     <membership>
     <providers>
     <add name="FBAMembershipProvider"
     type="System.Web.Security.SqlMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
     connectionStringName="FBADB"
     enablePasswordRetrieval="false"
     enablePasswordReset="true"
     requiresQuestionAndAnswer="false"
     applicationName="/"
     requiresUniqueEmail="true"
     passwordFormat="Hashed"
     maxInvalidPasswordAttempts="5"
     minRequiredPasswordLength="7"
     minRequiredNonalphanumericCharacters="1"
     passwordAttemptWindow="10"
     passwordStrengthRegularExpression="" />
     </providers>
     </membership>
    <roleManager>
     <providers>
     <add name="FBARoleProvider" connectionStringName="FBADB" applicationName="/"
     type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
     </providers>
     </roleManager>
     </system.web>

    Remember to match all of the options with what was entered in the machine.config.Save and close the file.

    sharepoint_2013_fba_config_5

The role and membership providers have now been setup for SharePoint. Continue on to Part 3 to configure SharePoint to use the membership provider we just setup.

Configuring Forms Based Authentication in SharePoint 2016, SharePoint 2019 and SharePoint Subscription Edition – Part 1 – Creating the Membership Database

Configuring forms based authentication (FBA) in SharePoint 2016, SharePoint 2019 and SharePoint Subscription Edition is exactly the same process as configuring it for SharePoint 2013.  I’ve recreated the SharePoint 2013 FBA tutorial specifically for SharePoint 2016, SharePoint 2019 and SharePoint Subscription Edition, using screenshots from SharePoint 2016 and Windows Server 2012 R2.  I have changed the tutorial to use the SharePoint FBA Pack to create the FBA users, but otherwise it remains the same and can be used interchangeably between SharePoint 2013 and SharePoint 2016/2019/Subscription Edition.

I’ll go through all of the steps required to setup FBA for SharePoint 2016, 2019 and Subscription Edition, from start to finish.  I’ve broken down the steps into 4 sections, so if you already have an existing membership database setup from a previous version of SharePoint, feel free to skip forward to Part 2.

Part 1 – Creating the Membership Database

Part 2 – Editing the Web.Config Files

Part 3 –  Configuring SharePoint

Part 4 – Adding Users to the Membership Database

You can also watch a video of the whole process on YouTube: Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019.

Part 1 – Creating the Membership Database

The first thing you need when configuring FBA for SharePoint is a place to keep all of the usernames and passwords. ASP.Net comes with a tool that we’ll use to create a membership database to store the logon information.

  • Navigate to c:\windows\Microsoft.NET\Framework64\v4.0.30319\
  • Run “aspnet_regsql.exe”aspnet_regsql.exe file
  • A welcome screen will appear. Click Next.aspnet_regsql wizard welcome
  • Select “Configure SQL Server for application services” and click Next.aspnet_regsql wizard task
  • Enter the name of your server and your authentication information.  In this case SQL Server is installed on the same server as SharePoint and I am logged in as an administrator and have full access to SQL Server, so I choose Windows Authentication.For the database name, I just leave it as <default>, which creates a database called “aspnetdb”.aspnet_regsql wizard select db
  • A Confirm Your Settings screen will appear. Click Next.aspnet_regsql wizard confirm
  • A “database has been created or modified” screen will appear. Click finish and the wizard will close.aspnet_regsql wizard finish
  • Now that the database has been created, we’ll have to give SharePoint permissions to read and write to it. We’re going to connect to the database with Windows Authentication, so we’re going to have to give those permissions to the service account that is being used to run SharePoint.First, let’s find out the service account that’s being used to run SharePoint. Open IIS, go to “Application Pools”. Take a look at the “Identity” that is being used to run the SharePoint application pools. On my test server, it happens to be my administrator account that is being used, but it will probably be different on your machine. Make note of the identity used.IIS Application Pool
  • Now that we know what account is being used to run SharePoint, we can assign it the appropriate permissions to the membership database we created.  Open up SQL Server Management Studio and log in as an administrator.SQL Server Management Studio
  • Under Security/Logins find the user that SharePoint runs as.  Assuming this is the same database server that SharePoint was installed on, the user should already exist.Right click on the user and click ‘Properties’.SQL Server Select Login
  • Go to the “User Mapping” Page. Check the “Map” checkbox for the aspnetdb database. With the aspnetdb database selected, check the “db_owner” role membership and click OK. This user should now have full permissions to read and write to the aspnetdb membership database.SQL Server Edit User Mapping

Continue to Part 2 – Editing the Web.Config Files.

SharePoint 2016 FBA Pack Released

FBAUserManagement

The SharePoint 2016 FBA Pack has been released. It was ported from the SharePoint 2013 FBA Pack (which was originally ported from the SharePoint 2007 CKS Forms Based Authentication Solution), and includes all of the features from the SharePoint 2013 FBA Pack:

  • User Management
  • Role Management
  • Membership Request Web Part
  • Password Recovery Web Part
  • Change Password Web Part
  • Change Password Menu Item

Go and grab it!

Mixing it up w/ Mixed SSL & SP 2010

The following is a post written by Tim Nugiel with instructions for creating a custom cookie handler for mixed mode authentication.  I reference it in my blog post Mixed Http and Https Content with SharePoint 2010. The original article was posted at: http://www.msngn.com/blog/lists/posts/post.aspx?id=5. I’ve reposted it here, as the original article appears to have gone offline.

 

Here is some very good reading if you want to learn more on the inner workings of federated authentication models w/ claims & sp2010:
http://msdn.microsoft.com/en-us/library/ee517293.aspx
So after much digging with firebug + the Firefox webdev extension to inspect my http sessions, I discovered 2 funny things about the cookie SharePoint is setting

1) It ignores most of the settings we put in our <forms tag and uses its own (see below)

2) No matter what attributes I set, the cookie was being written as a secure cookie, which prevented it from being transmitted via non-secure http requests
ssl_securecookie.png
I inspected the web.config some more and discovered that SharePoint is using a custom cookie handler to read/write cookies:

<cookieHandler mode="Custom" path="/">
<customCookieHandler type="Microsoft.SharePoint.IdentityModel.SPChunkedCookieHandler, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</cookieHandler>?

Enter Reflector:

once I opened up this class in reflector and traced the life of a cookie during an authentication session, it turned out that there was a hardcoded reference to the https protocol in the WriteCore method – this was trumping any of the manual settings we were trying to add in the web.config

ssl_reflector.png

The Fix:
 
Fortunately a custom cookie handler class is not that complex, so I created a new MSNGNChunkedCookieHandler class and updated the web.config entry
 
<cookieHandler mode="Custom" path="/" requireSsl="false" > 
 <!-- <customCookieHandler type="Microsoft.SharePoint.IdentityModel.SPChunkedCookieHandler, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> -->
 <customCookieHandler type="MSNGN.Utility.MSNGNChunkedCookieHandler, MSNGN.Utility, Version=1.0.0.0, Culture=neutral, PublicKeyToken=38c82c65bfb6cec0" />
 </cookieHandler>

This class invokes its base methods for the most part, I just slightly modified the WriteCore event w/ logic that removes the https hard coded reference.

using System;
using System.Web;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.IdentityModel;
using Microsoft.IdentityModel.Web;
using Microsoft.SharePoint.Administration;
using Microsoft.SharePoint.Administration.Claims;
 
namespace MSNGN.Utility
{
 /// <summary>
 /// This is an override of the Microsoft.SharePoint.IdentityModel.SPChunkedCookieHandler class
 /// with the WriteCore method extended to support both Secure & Non-Secure cookies
 /// </summary>
 public class MSNGNChunkedCookieHandler : Microsoft.SharePoint.IdentityModel.SPChunkedCookieHandler
 {
 
 private ChunkedCookieHandler m_CookieHandler;
 
 public MSNGNChunkedCookieHandler() : base()
 {
 this.m_CookieHandler = new ChunkedCookieHandler();
 this.m_CookieHandler.Path = "/";
 }
 
 public MSNGNChunkedCookieHandler(int chunkSize) : base(chunkSize)
 {
 this.m_CookieHandler = new ChunkedCookieHandler(chunkSize);
 this.m_CookieHandler.Path = "/";
 }
 
 protected override void DeleteCore(string name, string path, string domain, HttpContext context)
 {
 base.DeleteCore(name, path, domain, context);
 }
 
 protected override byte[] ReadCore(string name, HttpContext context)
 {
 return base.ReadCore(name, context);
 }
 
 /// <summary>
 /// Override of the WrieCore method to remove hard coded secure cookie flag
 /// which is required to support both http & non-http sessions
 /// </summary>
 protected override void WriteCore(byte[] value, string name, string path, string domain, DateTime expirationTime, bool secure, bool httpOnly, System.Web.HttpContext context)
 {
 //override the secure cookie setting
 //to enable both https & non https cookie sessions
 secure = false;
 
 if (context == null)
 {
 throw new ArgumentNullException("context");
 }
 if (context.Request == null)
 {
 throw new ArgumentException(null, "context");
 }
 if (null == context.Request.Url)
 {
 throw new ArgumentException(null, "context");
 }
 
 //if (string.Equals(context.Request.Url.Scheme, "https", StringComparison.OrdinalIgnoreCase))
 //{
 // secure = true;
 //}
 //else
 //{
 // secure = false;
 //}
 if (!string.Equals(path, "/", StringComparison.OrdinalIgnoreCase))
 {
 path = "/";
 }
 this.m_CookieHandler.Write(value, name, path, domain, expirationTime, secure, httpOnly, context);
 
 
 }
 
 }
}