Skip to main content
This page covers configuring the identity-provider side of SAML — what to click in your IdP, what to copy into Netgraph, and what the walled-garden must allow when the IdP is used for Captive Portal sign-in. The platform side is the same for every IdP: in the Admin Dashboard, Organization → Accounts → Federation → Add SSO Identity Provider, give it a name, pick the Authentication target (Admin Portal or Self Service), save, and copy the Service Provider values (Entity ID and ACS URL) the detail view shows — those are what your IdP needs. For how the two targets are used, see Organization SAML authentication. Captive Portal SAML uses the Self Service target — see SAML SSO module.

​
The IdP-side setup pattern

Every SAML IdP asks for the same information from the Service Provider (Netgraph):
  • Entity ID / Identifier — the unique identifier of the SP.
  • ACS URL / Reply URL — where the IdP should send the SAML response.
Both values are the Service Provider Recipient URL shown in Netgraph when you add the IdP configuration. And every SAML IdP gives back four things that Netgraph needs:
  • Sign-on URL — paste into Identity Provider Single Sign-On URL.
  • Issuer / Entity ID — paste into Identity Provider Issuer.
  • X.509 certificate — paste the Base64 content into X.509 Certificate.
  • Email attribute — mapped to the username claim Netgraph expects.

​
Azure AD / Entra ID

1

Create an Enterprise Application

In the Entra admin centre: Enterprise Applications → New application → Create your own application → Non-gallery. Give it a descriptive name (for example Netgraph — Admin Portal or Netgraph — Guest Wi-Fi). Click Create.
2

Open SAML single sign-on

On the new application, pick Single sign-on → SAML.
3

Fill in Basic SAML Configuration

Click Edit in section 1 and set:
  • Identifier (Entity ID) = Netgraph’s Service Provider Recipient URL.
  • Reply URL (Assertion Consumer Service URL) = the same URL.
Basic SAML Configuration section in Azure showing Entity ID and Reply URL fields
Save and close the dialog.
4

Add the username attribute claim

Click Edit in section 2 (Attributes & Claims) → Add new claim:
  • Name: username
  • Namespace: https://adminconsole.netsign-in.se/saml/attributes
  • Source: Attribute
  • Source attribute: user.mail
Save.
5

(Optional) Add a role claim

Only relevant for the Admin Portal target, and only if you want Netgraph roles to be driven by Entra group or role membership instead of a single default role.Add another claim:
  • Name: role
  • Namespace: https://adminconsole.netsign-in.se/saml/attributes
  • Source: Attribute
  • Source attribute: user.assignedroles
Then under App roles on the app registration, create roles matching Netgraph’s role names. Assign those roles to users or groups in Entra instead of the default User role.
Azure 'Create app role' form with Display name and Value fields
6

Download the certificate

In section 3 (SAML Signing Certificate), download the Certificate (Base64) and open it in a text editor. Paste the content into Netgraph’s X.509 Certificate field.
7

Copy URLs from section 4

  • Login URL → Netgraph Identity Provider Single Sign-On URL.
  • Azure AD Identifier → Netgraph Identity Provider Issuer.
8

Click Update Identity Provider in Netgraph

Save the configuration in the Admin Dashboard.
9

Assign users

Back in the Entra app, Users and groups → + Add user/group and assign the users or groups who should be able to sign in through this integration. Users who aren’t assigned are rejected by the IdP.
10

(Admin Portal only) Test

In section 5 (Test single sign-on with…), click Test and sign in as the current user. Entra opens Netgraph in a new tab with the expected role.

​
Walled-garden entries for Entra

When using Entra as the Self-Service IdP for Captive Portal SAML, add these hostnames to the Captive Portal walled garden:
  • login.microsoftonline.com
  • myapps.microsoft.com
  • account.live.com
  • aadcdn.msauth.net
  • aadcdn.msftauth.net
  • account.activedirectory.windowsazure.com

​
Google Workspace

1

Create a SAML app

In Google Admin: Apps → Web and mobile apps → Add app → Add custom SAML app. Enter a descriptive name.
2

Copy IdP values

Google shows you three values:
  • SSO URL → Netgraph Identity Provider Single Sign-On URL.
  • Entity ID → Netgraph Identity Provider Issuer.
  • Certificate → Netgraph X.509 Certificate.
Click Continue.
3

Enter SP details

Paste Netgraph’s Service Provider Recipient URL into both:
  • ACS URL
  • Entity ID
Name ID format: UNSPECIFIED. Name ID: Basic Information → Primary email.Click Continue.
4

Map the username attribute

In the Attributes section, click Add mapping.
  • Google Directory attribute: Primary email.
  • App attribute: https://adminconsole.netsign-in.se/saml/attributes/username
Click Finish.
5

Grant user access

On the new app’s User access page, enable ON for everyone (or restrict to the relevant Organisational Units). Save.
6

Save in Netgraph

Back in Netgraph’s Admin Dashboard, click Update Identity Provider.

​
Walled-garden entries for Google

  • accounts.google.com
  • accounts.google.<tld> — substitute your country TLD if Google redirects users through a regional subdomain.
  • fonts.gstatic.com
  • ssl.gstatic.com
  • lh3.googleusercontent.com
  • accounts.youtube.com

​
Okta

1

Create a SAML 2.0 app

Okta admin: Applications → Create App Integration → SAML 2.0 → Next. Enter a name.
2

Fill SP details

  • Single sign-on URL = Netgraph’s Service Provider Recipient URL.
  • Audience URI (SP Entity ID) = the same URL.
  • Name ID format = EmailAddress (or Unspecified; match Netgraph expectations).
3

Add attribute statement

Add an attribute statement mapping username (namespace https://adminconsole.netsign-in.se/saml/attributes) to user.email.
4

Finish and copy metadata

After the app is created, open Sign On → View SAML setup instructions and copy:
  • Identity Provider Single Sign-On URL → Netgraph.
  • Identity Provider Issuer → Netgraph.
  • X.509 Certificate → Netgraph.
5

Assign the app

Assignments → Assign to People (or Groups). Save in Netgraph.

​
Walled-garden entries for Okta

  • login.okta.com
  • ok12static.oktacdn.com
  • <your-tenant>.okta.com

​
Disabling MFA for the Captive Portal

Multi-factor authentication is great for sensitive resources, but it’s problematic during Captive-Portal sign-in: many devices restrict multitasking while captive, so the guest can’t easily open an authenticator app. For Entra deployments, the supported approach is Conditional Access — require MFA for every cloud app except the Captive-Portal Netgraph application.
1

Switch from per-user MFA to Conditional Access MFA

Per-user MFA and Conditional Access don’t mix. Under Users → Per-user MFA, confirm Multi-factor auth status is Disabled for the users this policy will apply to. Microsoft recommends this switch as a prerequisite for Conditional Access MFA.
2

Create a Conditional Access policy

Azure Active Directory → Security → Conditional Access → + New Policy. Name it clearly (for example Require MFA except Captive Portal).
3

Target users

Users → Include → All users.
4

Target cloud apps

  • Include → All cloud apps.
  • Exclude → add your Netgraph Captive Portal Enterprise Application.
5

Set access controls

Grant → Grant access with Require multifactor authentication checked. Click Select.
6

Enable and save

Flip Enable policy to On (or leave Report-only for a dry run first). Save.
MFA on Captive-Portal sign-in is a trade-off. Skipping it makes sign-in reliably work from captive devices; keeping it raises the security bar. Decide with your security team; whichever you pick, document it so the trade-off is explicit.
Google Workspace and Okta offer equivalent rule systems that let you exempt specific applications from MFA or step-up auth. The shape of the policy differs; the goal is the same.

​
Troubleshooting

SymptomMost likely cause
Entra “Invalid signature” on the ACS callbackSigning certificate expired — re-download and re-paste.
Sign-in completes but no login record appearsAttribute mapping wrong — check the username claim arrives as an email.
Browser loops back to the Captive PortalIdP hostnames missing from the walled garden.
Sign-in fails for users not assigned in the IdPExpected — assign them to the enterprise application.
For more general SAML debugging see Sign In Module issues.

Organization SAML authentication

The two IdP targets — Admin Portal and Self Service.

SAML SSO module

How the Captive Portal uses the Self-Service IdP.

Walled garden

Pre-auth reachability.