SAML 2.0 SSO

Federate WASViking with your IdP using SAML 2.0. Attribute mapping, default role policy, and a Google Workspace step-by-step.

WASViking^® implements SAML 2.0 as Service Provider. Sign your team in through your Identity Provider, with attribute mapping and optional group-to-role propagation. Default role on first SSO sign-in is Read-only by policy; promotion requires an existing Admin or Manager.

Supported Identity Providers

Any SAML 2.0 compliant Identity Provider works. The integration is tested against:

• Google Workspace (full step-by-step below)
• Microsoft Entra (Azure AD)
• Okta
• OneLogin
• JumpCloud
• Auth0

Service Provider endpoints

The same ACS and Entity ID apply to every organization. Routing is done by the primary email domain you configure on the WASViking side.

Required attributes

The IdP must send these attributes in the SAML assertion:

Casing matters. WASViking expects first_name and last_name in snake_case. CamelCase (firstName / lastName) is not recognized.

Configure on the WASViking side

Portal → Settings → System Settings → SSO & Identity → SAML.

The screen has:

Click Save SSO Settings.

Test the configuration with Test SSO before flipping enforcement on for everyone.

Default role policy

Every new account that signs in via SSO lands as Read-only by default. This is policy, not a setting: SSO-provisioned accounts are read-only on first login, regardless of IdP group memberships.

Promotion to any other role (Admin, Manager, Analyst) requires an existing Admin or Manager already on the platform. The promotion is done in Settings → Team, with audit log.

Why this matters: it gives the WASViking-side admin a moment to validate the new operator before granting elevated rights, even when the IdP would otherwise propagate a group-derived role automatically.

Group governance flow

Once SAML is enabled, operational access is driven from the IdP:

• Add a user to the WASViking-allowed group in your IdP → user gains access on next sign-in.
• Remove a user from the group → user loses access immediately on next session validation.
• Disable a user in the IdP → user loses access immediately.

The pattern is the IAM standard: lifecycle in the IdP, authorization in WASViking. You do not need to manage operator accounts on the WASViking side once SSO is on.

Group-to-role mapping (optional)

If your IdP sends a groupMemberships attribute, you can map specific groups to WASViking roles. Mappings apply on user promotion, not on first sign-in (which is always Read-only).

A user in multiple mapped groups receives the highest privilege among them at promotion time.

MFA

When SSO is enabled, MFA is handled by your IdP. WASViking does not prompt for its own MFA on SSO logins. This is the standard SP pattern.

For org-level break-glass access (when the IdP is down), Admins can enable Emergency Local Login under Settings → SSO. The flag has a 72-hour TTL and triggers a high-severity audit event when used.

Single Logout

If your IdP supports SLO, configure the Single Logout endpoint and WASViking honors logout requests originated at the IdP. Local logout in WASViking also issues SLO if the user signed in via SAML.

Enforcing SSO

Once SSO is tested, enable enforcement under Settings → System Settings → SSO & Identity. After this:

• Local password login is disabled for accounts on the configured email domain.
• API keys still work (they are not SSO-managed).
• Emergency Local Login remains available to break the loop.

Google Workspace step-by-step

This walkthrough mirrors the canonical WASViking Google Workspace SSO SAML Integration Guide v1.2.

Step 1 — Create a group for access control

Google Admin → Groups → Create group.

Group security:

• Type: Custom.
• Only invited members can join.
• Do not allow external members.

Click Create group.

Step 2 — Add users to the group

Open the group and click Add members. Only members of this group will be able to authenticate against WASViking.

Step 3 — Create the SAML application in Google Workspace

Google Admin → Apps → Web & Mobile Apps → Add App → Add custom SAML app.

Suggested app name: WASViking. Click Continue.

Step 4 — Save the Google IdP identity

On the Google IdP details screen, copy and keep:

• SSO URL
• IdP Entity ID
• X.509 Certificate

You will paste these into WASViking in Step 7.

Click Continue.

Step 5 — Configure WASViking as Service Provider

Fill exactly:

Click Continue.

Step 6 — Map attributes

Add these mappings exactly:

Click Finish.

Step 7 — Restrict to the group (governance)

Google Admin → Apps → Web & Mobile Apps → WASViking → Service status.

• Select Groups, search for WASViking Users.
• Set status to ON.
• Save.

Only members of WASViking Users can now sign in via this SAML app.

Step 8 — Optional: import via Metadata URL

If your IdP supports importing the SP automatically, use:

https://portal.wasviking.com/sso/saml/metadata

Step 9 — Configure on the WASViking side

In the WASViking Portal:

Settings → System Settings → SSO & Identity → SAML.

Fill:

• IdP Entity ID (from Step 4)
• IdP SSO URL / Metadata URL (from Step 4)
• IdP X.509 Certificate (paste between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----)
• Primary Email Domain (the domain users sign in with)

Toggle Enable SAML authentication and click Save SSO Settings.

Step 10 — Day-to-day operation

• Add a user to WASViking Users in Google Workspace → they gain access on next sign-in (lands as Read-only).
• Remove from the group → access revoked.
• Promote to Admin / Manager / Analyst → done by an existing Admin or Manager in WASViking.

Common problems

Security notes

• Only members of the IdP group can authenticate.
• WASViking follows least-privilege: first sign-in is Read-only.
• Role administration stays on the WASViking side.
• Every authentication and role change is captured in the audit log.

What this is not

WASViking does not implement OIDC. SAML 2.0 is the standard for enterprise SSO into security tools and is what every Identity Provider above supports natively. OIDC support is on the roadmap.

WASViking is not an Identity Provider. You cannot use WASViking to log into other SaaS tools.