Support Thread

Achieving Single-Sign-On

📅 👤 ASP Playground
Achieving Single-Sign-On — APG vNext Guide

This archived community thread from the APG vNext support forum discusses: Achieving Single-Sign-On.

About This Topic

You need to enable cookie based forms authentication for your site, as the forum uses forms authentication cookie to recognize logged in users. Single Sign O...

Getting Help with APG vNext

APG vNext is a powerful ASP.NET forum and community platform. For questions related to this topic:

If you need direct assistance, the support team is active in the community forum.

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

Common SSO Implementation Mistakes

Machine Key Mismatch Between Applications

When using Forms Authentication cookie sharing between the parent site and APG vNext, both applications must use identical machineKey values in their web.config. A mismatch causes the authentication cookie from the parent site to be rejected by APG vNext, even though the user is correctly authenticated on the parent site.

<!-- Both sites must share this exact machineKey -->
<machineKey
  validationKey="...64-char-hex..."
  decryptionKey="...48-char-hex..."
  validation="SHA1"
  decryption="AES" />

<!-- Also required: matching Forms Authentication settings -->
<forms
  name=".ASPXAUTH"
  domain=".yourdomain.com"
  loginUrl="/login.aspx"
  protection="All"
  timeout="60" />

The domain=".yourdomain.com" (note the leading dot) is essential — it makes the cookie valid across all subdomains of your domain. Without it, the cookie set by www.yourdomain.com is not readable by forum.yourdomain.com.

Clock Synchronisation for Token-Based SSO

Token-based SSO uses timestamps to prevent replay attacks. If the parent site's server clock is more than 5 minutes ahead of or behind the forum server's clock, valid tokens will be rejected as expired. Ensure both servers synchronise their clocks with an NTP server:

# Windows Server: force NTP sync
w32tm /resync /force

# Verify current time sync status:
w32tm /query /status

Missing allowedAudiences in OWIN/OAuth SSO

If integrating with a modern OWIN-based SSO provider (Azure AD, ADFS), the JWT token's aud (audience) claim must match the value configured in APG vNext. A mismatch produces a silent authentication failure where APG vNext accepts the token but doesn't create the session. Check APG.SSO.OAuth.AllowedAudiences in web.config matches the client ID of your APG vNext registration in the identity provider.

OAuth Integration: Google, Facebook, and Microsoft

APG vNext 5.x supports social login via OAuth 2.0 for Google, Facebook, and Microsoft accounts. This is a lighter-weight alternative to full SSO — members can choose to authenticate with their existing social account rather than creating a dedicated forum account:

<!-- Enable social login providers -->
<add key="APG.OAuth.Google.ClientID"      value="your-google-client-id" />
<add key="APG.OAuth.Google.ClientSecret"  value="your-google-secret" />
<add key="APG.OAuth.Facebook.AppID"       value="your-fb-app-id" />
<add key="APG.OAuth.Facebook.AppSecret"   value="your-fb-secret" />
<add key="APG.OAuth.Microsoft.ClientID"   value="your-ms-client-id" />
<add key="APG.OAuth.Microsoft.Secret"     value="your-ms-secret" />

Members using social login are created as regular APG vNext members but cannot change their password (it's managed by the OAuth provider). Their email, username, and avatar are imported from the OAuth profile on first login and can be updated from the member profile page thereafter.

Related Resources

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