C# Development: Microsoft Membership - Authentication
C# Development: Microsoft Membership - Authentication
ASP.NET membership gives .net developers a "built-in" way to validate and store user credentials for site authentication.
Scenario (Use Case)
If your .net site has protected content and/or requires authentication to view areas of it, Membership is an option for controlling site access. You can also use Membership to create and manage users and passwords, expose unique identification for authenticated users, use with ASP.NET personalization and more. (See MSDN for full documentation).
A .NET site's Membership application, and site users, roles and groups are not to be confused with CMS users and groups and authentication for the CMS itself (which is handled by the CMS); this membership application applies to the published site and published content and will be standalone and function outside of the CMS on the webhost.
- A Membership provider, which can be a Database on the web host (MySql, MSSQL, etc.), windows Live ID, active directory, or an existing source of information about users (see How Membership Works on MSDN link below)
- Site architecture/membership requirements, i.e., what is your site use case for membership?
Membership can be implemented with Crownpeak by following a few steps. A sample Membership project has been implemented on cms.crownpeak.com/training1 in /Sandbox/Microsoft Membership Example/
Configure your server-side .net project
As with other .NET solutions, it is a best practice to configure and create your source .net project outside of the CMS. You will then configure your CMS instance to publish a site that mirrors the structure of it. See Dot Net and Crownpeak Templates for more information.
Membership Management pages
Several pages will need to be created to manage your membership application when your site is published. See http://msdn.microsoft.com/en-us/library/tw292whz(v=vs.100).aspx for additional reference.
In general, these management pages allow the site admin to manage the Roles, Groups and Users for the published site.
Standard Authentication Form (s)
- Login Page and/or subform (top of menu, for instance)
- Login Password recovery
- Account Management
- Account Registration
- User Role Management - Allows site admins to create access roles. Recommended: Admin, Super Admin and Registered User.
- User Management - Allows admins to administer users.
Additional access restrictions may be imposed to secure the site.
Use of Membership NameSpaces
- Once you've brought in membership namespaces, you can use the ASP.NET login controls (Login, LoginView, LoginStatus, LoginName, and PasswordRecovery) throughout your published site.
- These encapsulate virtually all of the logic required to prompt users for credentials and validate the credentials in the membership system.
Web Config Settings and Examples
Web.config files control the authentication settings for folders/sections. Your main site web.config will include:
- Connection string to connect to the membership provider
- Authentication setting requirements on a directory-by-directory basis
Additional web.configs should be implemented as in the sample project to manage access in sections. If you have a large site, consider creating a template to publish web.configs as needed with common options easily configurable through the CMS.
Following is an example web.config to allow only registered users:
And here is an example web.config denying all but admin users:
Select and configure your membership database/provider
Membership can support several different database management systems and providers for storing site-user information.
- Queries with stored procedures
MSSql (SQLExpress or SQL Server)
- Queries with .net code/functions
Adding Custom Fields to DBMS providers
- If using a database as your membership provider, custom fields can be integrated with the membership data by using the UserId as a foreign key in the custom table. (i.e., Create your custom table, link to the membership table by UserId (as a foreign key) and add as many fields as needed.)
NOTE: If the .net project is built locally, with a local database as the membership provider, make sure to update all connection strings or database references when transferring to the CMS to point to the production database.
Remember that the database must be configured to work with your webhost and published site. It does not work inside of the Crownpeak CMS and preview environment.
Configure your CMS
Once you have the membership portion of your project developed and tested, you're ready to import it into the CMS.
- See Implementing ASP.Net Web Sites and Web Applications in Crownpeak for more information
- Stage and live can share a membership provider, in this case you can "hide" the admin pages on the stage server to reduce exposure
- Create a local dev environment complete with your membership provider for creating and testing your membership implementation that will mirror the configuration on the webhost.
- More advanced architectures (restricted IP for example) may also be configured by Crownpeak hosting (discuss your hosting requirements with Crownpeak support).
- Creating your first admin account can be done directly in the database (requires working with hosting or membership administrator).
- Alternatively, you can enable your initial admin accounts by modifying the web.config of the user management folder to allow you to access these pages without checking your credentials. Then, set up your admin users with credentials, and finally make sure to re-enable restrictions for admin pages in the web config.
- Connection string is incorrect or connecting to the wrong database / membership provider (such as attempting to connect to the local Dev provider on the production site)
- Web.config files are not properly configured to allow/disallow authorization by membership groups