This archived community thread from the APG vNext support forum discusses: Integration with ASP.NET Membership Providers.
About This Topic
Our software uses Forms Authentication, so it is very easy to achieve Single-Sign-On between your site and the forum. There are 3 possible scenarios for us...
Getting Help with APG vNext
APG vNext is a powerful ASP.NET forum and community platform. For questions related to this topic:
- Browse the Knowledge Base for documented solutions
- Search the community forum for similar threads
- Check the FAQ for common questions and answers
- Review the Installation and Upgrade guides
If you need direct assistance, the support team is active in the community forum.
Integrating APG vNext with ASP.NET Membership Providers
APG vNext uses ASP.NET Forms Authentication and can be configured to integrate with any ASP.NET Membership Provider. This allows you to share a single user database between APG vNext and other ASP.NET applications on the same server, so users can log in once and be recognized across all applications without maintaining separate accounts.
How APG vNext Handles Authentication
By default, APG vNext manages its own user table in its SQL Server database. It implements a custom Membership Provider that stores hashed passwords, user profiles, and group assignments in the APG-specific schema. When you want to share membership with another ASP.NET application, you have two integration paths: configure APG vNext to use the standard SqlMembershipProvider pointing at a shared database, or implement a custom Membership Provider bridge that proxies authentication between systems.
Using SqlMembershipProvider for Shared Membership
The simplest integration path is using ASP.NET's built-in SqlMembershipProvider with a shared database. Both APG vNext and your other application point to the same ASP.NET membership database. In APG vNext's web.config, configure the membership provider section to reference the shared connection string and set the applicationName attribute to the same value used in your other application. This is critical: if the application names differ, users are isolated per application even if they share the same physical database, because ASP.NET Membership scopes user records by application name.
Forms Authentication Shared Cookie
For true single sign-on where a user logged into one application is automatically recognized by the other, both applications must share the same Forms Authentication cookie. This requires identical machineKey values in both applications' web.config files and the cookie configured with a domain scope that covers both applications. Set the domain attribute on the forms element to your root domain (for example, .yourdomain.com) so the cookie is sent to all subdomains. Never use auto-generated machine keys when sharing authentication across applications — generate them explicitly and keep the same values in every application that needs to share authentication state.
Profile and Role Synchronization
When using a shared Membership Provider, APG vNext forum-specific data such as group memberships, post counts, signatures, and avatars is still stored in the APG database. The shared Membership Provider only handles authentication credentials. Ensure that when a new user registers in either the shared application or APG vNext, the corresponding records are created in both systems. Implement this via APG vNext's new user event hook or a database trigger that creates the necessary cross-database records on user creation.
Custom Membership Provider Implementation
If your existing application uses a custom Membership Provider with a proprietary user schema, create a bridge provider class that inherits from MembershipProvider and delegates authentication calls to your existing system while returning the interface contract APG vNext expects. This is the most flexible but most complex integration approach. The minimum methods to implement are ValidateUser, GetUser, GetUserNameByEmail, and CreateUser. All other methods can throw NotImplementedException if the corresponding features are not needed in your integration scenario.
Testing the Integration
After configuring the integration, test these scenarios: new user registration in APG vNext, new user registration in the companion application, login from APG vNext after registering in the companion application, login from the companion application after registering in APG vNext, password reset from both sides, and account lockout behavior. Each of these exercises a different part of the Membership Provider interface and can expose integration gaps that are not obvious from configuration alone.
Common Integration Issues
The most frequent issue is mismatched applicationName values causing users created in one application to be invisible in the other. Second most common is a machine key mismatch causing the Forms Authentication cookie from one application to be rejected by the other, forcing users to log in again when navigating between applications. Third is the password hashing format: if one application uses MD5-hashed passwords and the other uses HMACSHA256, passwords stored by one will fail validation in the other. Always align hashing configurations before migrating existing user accounts between systems.
Security Considerations
Shared membership across applications increases the attack surface. A vulnerability in one application can be leveraged to compromise accounts used in another. Mitigate this by ensuring all applications in the shared membership pool are kept up to date, using HTTPS exclusively to prevent cookie theft, setting appropriate cookie expiration and sliding expiration policies, and implementing account lockout thresholds to prevent brute-force attacks across all integrated applications simultaneously.
Looking for more help? Browse the support forum or check the Knowledge Base.