Single Sign-On (SSO) & SCIM Provisioning

Single Sign-On (SSO) & SCIM Provisioning

SSO lets people sign in to ZenFlip with the account they already have at your organization, so there is no separate ZenFlip password to issue, reset or revoke. SCIM goes a step further and creates and deactivates ZenFlip accounts automatically as people join and leave.

Both are Enterprise plan features, and both are set up by an organization owner or admin under Settings → SSO / SAML.

What you need before you start

• Enterprise plan

• Admin access to your identity provider (Okta, Microsoft Entra ID, Google

Workspace, or any SAML 2.0 provider)

• Your provider's metadata URL, if it publishes one — most do

Setting up SAML single sign-on

1. Import your provider's metadata

On Settings → SSO / SAML, paste your identity provider's metadata URL into Import from your IdP and choose Import. This fills in the entity ID, sign-in URL, single logout URL and signing certificates for you.

Import rather than typing these in if you possibly can. A metadata URL is re-read daily, so when your IT team rotates the signing certificate — which every provider does periodically — ZenFlip picks up the new one automatically. Values typed in by hand do not update, and sign-in stops working the day the old certificate expires.

If your provider does not publish a URL, expand No URL? Paste the metadata XML instead, or fill in the fields below by hand.

2. Give your provider ZenFlip's details

Under Service Provider (SP) Details you will find the values your provider needs:

There is also an SP Signing & Encryption Certificate. Upload it to your provider if it verifies signed requests or encrypts assertions — many providers do neither by default, in which case you can ignore it.

3. Tell ZenFlip which email domains you own

Fill in Email domains with the domains your provider is responsible for, for example yourschool.org. When someone types an address at one of those on the ZenFlip sign-in page and chooses Sign in with SSO, they are sent straight to your provider.

4. Turn it on

Save the configuration, then switch Single Sign-On (SSO) on. Test it with one account before you tell anyone else.

Setting up OpenID Connect instead

If your provider offers OpenID Connect and you would rather use it than SAML, choose OpenID Connect as the provider type. There are no certificates to manage.

1. In your provider, create an OIDC web application and copy ZenFlip's

Redirect URI into it exactly as shown on the settings page. A value that differs by so much as a trailing slash is rejected at sign-in.

1. Also copy the Post-logout redirect URI if you want single logout — see

below.

1. Back in ZenFlip, enter the Issuer URL (the base address only — ZenFlip

reads /.well-known/openid-configuration from it), the Client ID and the Client secret.

1. Fill in Email domains, save, and switch Single Sign-On on.

Everything else — email domains, enforcement, group to role mapping — works the same as it does for SAML.

Requiring everyone to use SSO

Once SSO is working, switch on Enforce SSO to stop people signing in with a ZenFlip password.

By default, organization owners keep a password as a way back in. This is deliberate: if your provider's certificate expires or an attribute changes, enforcing SSO without an exception would lock every administrator out of your own organization. If your security policy does not allow any exception, clear Let owners still sign in with a password.

Signing people in

• From ZenFlip — choose Sign in with SSO on the sign-in page, enter a

work email address, and ZenFlip forwards you to your provider.

• From your provider's portal — if your provider shows a ZenFlip tile or

app icon, choosing it signs the person straight in.

Both work. Neither needs any extra configuration beyond the steps above.

Single logout

Signing out of ZenFlip can also end the person's session at your identity provider. This matters most on shared or classroom devices: without it, signing out of ZenFlip and returning silently signs the same person back in, because their provider session is still open.

SAML — fill in IdP Single Logout URL. Importing your provider's metadata usually fills it in for you. Some providers will not enable single logout until you have given them ZenFlip's signing certificate, which is on the same settings page.

OpenID Connect — copy the Post-logout redirect URI from the settings page into your provider, alongside the sign-in redirect URI you registered when you set OIDC up. Providers reject a post-logout address they have not been told about, and the refusal appears on their own error page rather than in ZenFlip.

Either way this is optional. Without it, signing out still ends the ZenFlip session — it just leaves the provider session alone.

Mapping groups to roles

Under Group to role mapping, give people a ZenFlip role based on the groups your provider sends. For example, a group called Library Staff can map to Editor.

• Anyone whose groups match nothing gets the Viewer role.

• If several groups match, the strongest role wins.

• Group names are matched without regard to capitalisation.

• Owner cannot be granted this way. Owner controls billing and can switch

SSO off, so it stays a deliberate action inside ZenFlip.

Mappings apply when an account is first created. Someone whose role you have already changed by hand keeps that role.

When sign-in does not work

"Your identity provider did not send an email address"

ZenFlip needs an email address to identify the account. Ask whoever manages your provider to include an email claim for the ZenFlip application.

If the attribute exists but has an unusual name, open What your IdP sent us on the settings page. It shows exactly which attributes arrived on the most recent sign-in attempt — including failed ones, which is usually when you need it. Put the right name into the matching Attribute mapping field.

"We could not verify the sign-in response from your identity provider"

Most often the signing certificate has expired or was rotated. Import your provider's metadata again, or paste the current certificate.

ZenFlip emails organization admins 30, 14, 7 and 1 days before a certificate expires, so this should not take you by surprise — provided an admin address is reachable.

"Single sign-on is not set up for that email domain"

The domain typed on the sign-in page is not listed under Email domains. Add it, or sign in with a password.

"This sign-in link has already been used"

Sign-in responses can only be used once, which prevents them being replayed. Start again from the sign-in page.

SCIM provisioning

SCIM lets your identity provider create, update and deactivate ZenFlip accounts automatically, so you do not invite people by hand and leavers lose access without anyone remembering to remove them.

1. On Settings → SSO / SAML, scroll to SCIM Provisioning and choose

Generate token. Copy it immediately — it is not shown again.

1. In your identity provider, add ZenFlip as a provisioning application using

the SCIM Endpoint shown on the same screen and the token as the bearer secret.

ZenFlip supports users and groups, including group membership changes.

People created by SCIM get the Viewer role. If you have set up group mappings, their role is applied the first time they sign in.

Frequently asked

Does SSO apply to readers? No. SSO and SCIM cover your own team — the people who sign in to ZenFlip to create and manage publications. Reader accounts are separate.

Which providers are supported? Any SAML 2.0 provider, including Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin and ADFS.

Can people still use a password after SSO is on? Yes, unless you switch on Enforce SSO.

What happens to existing accounts? Someone signing in through SSO with the same email address as an existing ZenFlip account is matched to that account. Their role and content are unchanged.

Is my configuration visible to anyone else? No. Your signing keys and secrets are encrypted and never sent to a browser. Organization admins can see the configuration screen; nobody else can.