Support Thread

Achieving Singlesignon

Achieving Singlesignon — APG vNext Guide

Achieving Singlesignon — an archived discussion from the APG vNext support community.

About This Topic

This thread covers achieving singlesignon in the context of APG vNext, the ASP.NET forum and community platform. The community includes APG developers and experienced administrators who can help with similar questions.

APG vNext Support

Implementing Single Sign-On with APG vNext

Single Sign-On (SSO) allows members to authenticate once — typically on a parent website or corporate portal — and access the APG vNext forum without a separate login. This is critical for organisations where the forum is one component of a larger web presence and requiring a separate forum login creates friction and duplicate account management overhead.

APG vNext supports SSO through two primary mechanisms: the Custom MembershipProvider approach (deep integration with full user lifecycle control) and the Token-Based SSO approach (lightweight, stateless handshake suitable for simple parent-site integrations).

Approach 1 — Custom MembershipProvider

This approach replaces APG vNext's built-in membership system with a custom provider that delegates authentication to your existing user store (SQL database, LDAP, Active Directory, or a third-party identity provider).

<!-- web.config — register your custom MembershipProvider -->
<membership defaultProvider="CustomSSOMembershipProvider">
  <providers>
    <clear />
    <add name="CustomSSOMembershipProvider"
         type="YourNamespace.CustomSSOMembershipProvider, YourAssembly"
         connectionStringName="YourAppConnection"
         enablePasswordReset="false"
         requiresQuestionAndAnswer="false" />
  </providers>
</membership>

Your custom provider must implement System.Web.Security.MembershipProvider and at minimum override ValidateUser(username, password) to authenticate against your existing user store.

Approach 2 — Token-Based SSO Handshake

For parent sites that cannot easily implement a .NET MembershipProvider, APG vNext supports a token-based SSO handshake:

  1. The parent site generates a signed token containing the user's username, email, and timestamp
  2. The user is redirected to https://yourforum.com/sso?token=SIGNED_TOKEN
  3. APG vNext validates the token signature using a shared secret, creates or updates the member record, and logs the user in
  4. The user lands on the forum fully authenticated
// Parent site token generation (C# example)
using System.Security.Cryptography;
using System.Text;

string payload  = $"{{username:{username},email:{email},ts:{unixTimestamp}}}";
string b64      = Convert.ToBase64String(Encoding.UTF8.GetBytes(payload));
string sig      = ComputeHMACSHA256(b64, sharedSecret);
string ssoUrl   = $"https://yourforum.com/sso?token={b64}&sig={sig}";

The shared secret is configured in APG Admin Panel → Settings → SSO → Token Secret. Keep this value private — it is equivalent to a master password for your forum's authentication system.

Active Directory Integration

For corporate environments where users authenticate against Active Directory, APG vNext's LDAP MembershipProvider connects directly to your AD domain:

<!-- LDAP / Active Directory configuration -->
<appSettings>
  <add key="APG.LDAP.Enabled"      value="true" />
  <add key="APG.LDAP.Server"       value="ldap://dc.yourdomain.com" />
  <add key="APG.LDAP.Domain"       value="YOURDOMAIN" />
  <add key="APG.LDAP.BaseDN"       value="DC=yourdomain,DC=com" />
  <add key="APG.LDAP.UserOU"       value="OU=Users,DC=yourdomain,DC=com" />
  <add key="APG.LDAP.ServiceUser"  value="[email protected]" />
  <add key="APG.LDAP.ServicePass"  value="encrypted-service-password" />
</appSettings>

Testing Your SSO Implementation

Verification Checklist

  • Log in via SSO as a new user — verify APG vNext creates the member account automatically
  • Log in via SSO as an existing user — verify existing profile data is preserved
  • Attempt login with an invalid token — verify APG vNext rejects it with an appropriate error
  • Test token expiry — tokens older than 5 minutes should be rejected to prevent replay attacks
  • Verify the user is redirected back to the page they originally requested after SSO authentication

Azure AD and ADFS Integration with APG vNext

Modern enterprise deployments often use Azure Active Directory (Azure AD) or Active Directory Federation Services (ADFS) as the central identity provider. APG vNext 5.x supports both through an OWIN middleware layer that handles the OAuth 2.0 or SAML 2.0 handshake transparently.

Registering APG vNext in Azure AD

  1. In Azure Portal, go to Azure Active Directory → App Registrations → New Registration
  2. Name: "APG vNext Forum"
  3. Redirect URI: https://yourforum.com/signin-azuread
  4. Copy the Application (Client) ID and Directory (Tenant) ID
  5. Under Certificates & Secrets, create a new Client Secret
<!-- web.config: Azure AD SSO configuration -->
<add key="APG.AzureAD.TenantID"      value="your-tenant-guid" />
<add key="APG.AzureAD.ClientID"      value="your-client-guid" />
<add key="APG.AzureAD.ClientSecret"  value="your-client-secret" />
<add key="APG.AzureAD.Enabled"       value="true" />
<!-- Map Azure AD groups to APG vNext groups -->
<add key="APG.AzureAD.AdminGroupID"  value="azure-group-guid-for-admins" />
<add key="APG.AzureAD.ModGroupID"    value="azure-group-guid-for-mods" />

Claims Mapping

Azure AD tokens contain claims — key-value pairs about the authenticated user. APG vNext uses these to populate the member profile on first login and to sync them on subsequent logins:

// Default APG vNext claim mapping:
// "preferred_username" → APG member username
// "email" or "upn"    → APG member email
// "name"              → APG member display name
// "groups"            → APG group membership

// Customise mapping in web.config if your tenant uses different claims:
<add key="APG.AzureAD.ClaimMap.Username" value="preferred_username" />
<add key="APG.AzureAD.ClaimMap.Email"    value="email" />
<add key="APG.AzureAD.ClaimMap.Name"     value="name" />

Diagnosing SSO Failures

SSO failures are often silent — the user is redirected to the forum but not logged in, or is logged in but has no group memberships. Enable SSO debug logging to capture the full token exchange:

<!-- Enable SSO debug logging -->
<add key="APG.SSO.Debug" value="true" />
<!-- Log location: Admin Panel → Logs → SSO Debug Log -->

<!-- Or write to a file for investigation -->
<add key="APG.SSO.Debug.LogFile" value="~/logs/sso-debug.txt" />

With debug logging enabled, every SSO authentication attempt is logged with the full decoded token, the claims received, and the APG vNext membership record that was created or updated. This is the fastest way to diagnose claim mapping or group membership issues.

Related Resources

Looking for more help? Browse the support forum or check the Knowledge Base.