This project is read-only.

Project Description

Custom Forms Based Authentication solutions for SharePoint 2010 and 2013 Preview using Claims Based Authentication concepts.

*NEW: Updated for SharePoint 2013 and Visual Studio 2012 Professional. Previous solution for 2013 was for Preview edition using Visual Studio RC.

Includes Visual Studio 2010 and 2012 RC solutions that create SharePoint Solution Packages (WSP) that deploy the project to SharePoint 2010 and 2013 Preview. This will add all necessary files and assemblies to your SharePoint environment so that you can authenticate users with a custom SQL Server database table, or Twitter!


The Visual Studio projects contain the following content:

Custom Classes

  • General Utilities: GenUtil.cs, Logger.cs, TwitterData.cs
  • OAuth.cs, OAuthTwitter.cs: libraries that facilitate OAuth requests and specific Twitter requests to authenticate and authorize users.
  • CustomDbUsersContext.dbml: Linq to Sql context for the custom SQL Server table of users for one of the providers.

Membership Providers

  • The membership provider that retrieves and validates users from the custom SQL Server database table (script included in project to create user table). This table should only be used for demo purposes, not a strong way of saving user identities (password in plain text).

  • The membership provider that is used to resolve user identities (Twitter screen names) and validate Twitter screen names. NOTE: the validate user function is using a special technique to handle passwords, since this membership provider is intended to be used with an Oauth login page, the password is unavailable. This is better than a blank password, since it relies on a shared algorithm to generate the proper encrypted, hashed, salted, password (made from username and a salt). This is demo only and in production a true one-way cryto-hash algorithm or HMAC should be used.

Role Providers

  • The role provider that also uses the custom SQL Server database table and includes one dynamic role, with a hard coded named "DynamicAdmins", but users can "slide" in and out of the role based on the database field for each user. This demonstrates an interesting concept for using Dynamic Roles instead of typical Groups/Containers that users are added and removed on a regular basis. Using dynamic roles, any criteria can be used to determine if a user is in a role or not.

  • This role provider does not actually provide any roles to be used, but was necessary to prevent an index out of bounds error in SP2013 when it was looking for a matching roleManager along with the membership provider. It simply returns false or empty role collections.

Custom Login Pages

Numerous login pages are added that change the way SharePoint authenticates users.
  • CustLoginOOB.aspx: provides standard username and password fields, but then challenges the user with an additional "agreement" that user must agree to before logging in. This is a standard Web Forms page, not using the SharePoint Master Page. This demonstrates the power of using custom login pages, changing how users login to SharePoint.
  • CustLoginTwitter.aspx: redirects the user to Twitter using OAuth, where the user can then authenticate using their Twitter credentials (on a Twitter server in the "cloud"), and then Authorize Twitter to redirect back to SharePoint and allow SharePoint to make subsequent connections to post new tweets, and get user Twitter information.

Custom Web Parts

  • CustLoginOOBWebPart: this web part provides the same login functionality as the CustLoginOOB.aspx page. But instead of being a separate page it is encapsulated in a web part. This is intended to be used in an anonymous enabled SharePoint site, and added to a web part/layouts page where users can login using the web part instead of being redirected to a different login page. This is a common way for users to "sign in" on anonymous enabled sites instead of being bounced to separate login pages.
  • TwitterPostWebPart: this web part reads the current user's twitter info (screen name, latest tweet, latest tweet timestamp), and also allows the user to post new tweets to Twitter. It is only intended to be used when logged in using the Twitter Membership Provider and OAuth.

Sql Script

The script needed to create the Custom SQL Server table used by the Linq to Sql and CustomDbUsersProviders (membership and role).

Web.config Changes

Also provided are the different web.config files that are impacted by using custom authentication. These files are included in the project, but for reference only since they are not deployed to the server and the updates are not done automatically. The following web.config files need changes for custom authentication to work:
  • Central Administration: registering peoplepickers (if wild cards are used by code for user searches), registration of membership and rolemanager providers
  • STS (Security Token Service): registration of membership and rolemanager providers
  • Web Applications (1 or more): registration of membership and rolemanager providers, connectionstrings if needed, appsettings if needed, peoplepickers if needed

Deployment Instructions

The following are a loose set of instructions for installing this project and getting custom authentication to work in both SharePoint 2010 and 2013.
  1. Create or use a single SharePoint web application, then extend it to 1 or more zones.
  2. Each zone can be configured to use a different form of authentication (mixed, windows, FBA) while providing the same content and GUI to users.
  3. Deploy the WSP solution packages using STSADM or PowerShell or Manually. This adds the assemblies to the GAC and adds files to the HIVE (14 and 15).
  4. Edit the web.config files as per the sample files included in the project.
    1. CA: needs membership, roleManager, and peoplepicker. Also, setting the "defaultProvider" may be necessary to get central administration peoplepickers to resolve FBA users.
    2. STS: needs membership, roleManager
    3. Web Application using Custom Db Users Auth: membership and roleManager providers
    4. Web Application using Twitter Auth: membership and roleManager providers, and appSettings
  5. Edit web application authentication providers in CA, specify custom login page urls and FBA provider names (membership and roleManager) for each zone:
    1. Provider Names: CustomDbUsersMP, CustomDbUsersRP, CustomTwitterMProvider, CustomTwitterRProvider
    2. 2010 Login paths: /_layouts/fbaaddons/custloginoob.aspx, /_layouts/fbaaddons/custlogintwitter.aspx
    3. 2013 Login paths: /_layouts/fbaaddons2013/custloginoob.aspx, /_layouts/fbaaddons2013/custlogintwitter.aspx
  6. Assign a FBA user as a site collection administrator or "full control" user policy for a web application/zone, so "first" user can login to site and add other users.
  7. Activate FBAAddOns site collection feature in sites where web parts (login and Twitter info/tweeter) are needed.
  8. For Twitter authentication to work:
    1. You must register an account with and create an "application", raise the application permissions to read and write (default is read), add a Callback Url (important) even though the application overrides it when redirecting user to Twitter for auth.
    2. Save the generated Consumer Key and Consumer Secret in the web.config appsettings for the Twitter Auth SharePoint Web Application. This is used by the application to make OAuth requests to Twitter.

Sample SharePoint Configuration Used

  • A single web application using Claims Based Authentication was created:
    • Default Zone
    • No anonymous
    • Enable Windows Auth selected
    • NTLM selected, Basic also selected
    • Enable Forms Based Auth selected
    • Providers: CustomDbUsersMP, CustomDbUsersRP
    • Default Sign In Page
    • Client Integration selected
  • Default Zone extended,
    • Internet Zone
    • No anonymous
    • Enable Windows Auth NOT selected
    • Enable FBA selected
    • Providers: CustomDbUsersMP, CustomDbUsersRp
    • Custom Sign In Page: /_layouts/fbaaddons/custloginoob.aspx
    • Client Integration selected
  • Default Zone extended:
    • Custom Zone
    • Anonymous selected (also requires another web application settings configured for anonymous access, and also a setting in the site collection settings configured)
    • Enable Windows Auth NOT selected
    • Enable FBA selected
    • Providers: CustomDbUsersMP, CustomDbUsersRp
    • Custom Sign In Page: /Custom%20Pages/CustomLogin.aspx (this is web part page created in a web part page library in the SharePoint site which contains the CustLoginOOBWebPart)
    • Client Integration selected
  • Default Zone extended:
    • Intranet Zone
    • No anonymous
    • Enable Windows Auth NOT selected
    • Enable FBA selected
    • Providers: CustomTwitterMProvider, (for SP2013, CustomTwitterRProvider is needed to prevent error in STS)
    • Custom Sign In Page: /_layouts/fbaaddons/CustLoginTwitter.aspx
    • Client Integration selected
  • User Policies for each Zone was created, to grant "Full Control" permissions for an FBA user so the user can login to the FBA site and grant further permissions for other users. (This uses the CustomDbUsersMP and CustomTwitterMProvider membership providers to find users via the SharePoint People Picker webcontrol.)

Screenshots Available

Screen Shots


Created by Ben Steinhauser, B&R Business Solutions,

Last edited Jan 4, 2013 at 4:42 AM by bandrben, version 12