Skip to main content
With single sign-on, your users sign in to Popsink with their corporate account. They don’t need a Popsink password. Authentication happens at your identity provider (IdP), so your password policy, MFA and conditional-access rules apply to Popsink as they do to your other applications. Popsink supports two protocols: On top of an SSO connection, you can turn on SCIM provisioning. Your IdP then creates, updates and deactivates Popsink users for you, and your IdP groups set their organization role. See SCIM provisioning.
SSO is set up with the Popsink team. It isn’t self-serve yet (see the roadmap). The IdP side takes about fifteen minutes. We activate the connection on our side as soon as we receive your metadata.

​
How it works

Popsink authenticates users through Clerk, our identity platform. Each SSO connection is tied to one or more email domains that you own, for example acme.com.
  1. A user opens the Popsink console and enters their work email, jane@acme.com.
  2. Popsink sees that acme.com has an SSO connection and redirects the browser to your IdP.
  3. The user authenticates there, with MFA if your IdP asks for it.
  4. The IdP sends a signed SAML assertion or OIDC token back to Popsink. The user lands in the console, signed in.
This flow is SP-initiated: it starts from the Popsink sign-in page. Starting from the Popsink tile in your IdP’s app portal (IdP-initiated) is off by default. We can enable it on request.
Once SSO is active for a domain, every user with an email on that domain must sign in through your IdP. Password and social sign-in stop working for those addresses. Existing Popsink accounts are kept and linked to the SSO identity by email, with all their organizations and roles.

​
Before you start

Have the following ready:
  • Admin access to your IdP, so you can create an application (SAML) or an app registration / client (OIDC).
  • The email domains to route to SSO. You must own them, and Popsink may ask you to prove ownership.
  • A test user on one of those domains, assigned to the application. You will use it for the first sign-in.

​
Set up SSO

1

Request an SSO connection

Email support@popsink.com with:
  • your Popsink organization name,
  • the email domain(s) to connect,
  • the protocol (SAML or OIDC) and your identity provider.
We create the connection and reply with the service provider values you need in the next step.
2

Create the application in your IdP

Create the application with the values we sent. The settings for each protocol are described below: SAML 2.0 or OpenID Connect.Assign the users or groups who should have access to Popsink to the application.
3

Send us your IdP details

  • SAML: the IdP metadata URL. Alternatively, send the metadata XML file, or the SSO URL, IdP entity ID and signing certificate.
  • OIDC: the issuer / discovery URL, the client ID and the client secret.
Don’t send an OIDC client secret in plain text by email. Ask us for a secure channel, and we will send you a one-time link.
4

Test and go live

We activate the connection. Then sign in with your test user at the Popsink console by entering its email address. You should reach your IdP and come back signed in.Once the test succeeds, SSO applies to everyone on the connected domains.

​
SAML 2.0

​
Values to enter in your IdP

We send you these values when we create the connection. They are unique to it. Use these settings for the rest of the application:

​
Attributes

Popsink identifies users by email address, so the email must match the address used to invite them into Popsink. If your IdP already sends standard claim names, you don’t need to rename them. For example, Entra ID sends http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress. Tell us which names you use and we will map them on our side.
  1. In Entra ID → Enterprise applications, click New application → Create your own application and choose Integrate any other application you don’t find in the gallery (Non-gallery).
  2. Open Single sign-on → SAML.
  3. In Basic SAML Configuration, set Identifier (Entity ID) to the Popsink SP Entity ID and Reply URL to the Popsink ACS URL.
  4. Under Attributes & Claims, make sure the Unique User Identifier (Name ID) is user.mail or user.userprincipalname, whichever holds the user’s real email address.
  5. Under Users and groups, assign the users or groups who should have access.
  6. Copy the App Federation Metadata Url from the SAML Certificates section and send it to us.

​
OpenID Connect

Create an OIDC application of type web application that uses the authorization code flow. The ID token must carry a verified email claim. given_name and family_name are used when present. Send us the issuer URL (the base of /.well-known/openid-configuration), the client ID and the client secret, over a secure channel.

​
Users, organizations and roles

SSO controls who can sign in. What they can access is still managed in Popsink.
  • The account is created at first sign-in. Users don’t need a Popsink account beforehand.
  • Access to an organization requires an invitation. An organization admin invites the user by email from the console. At the user’s first SSO sign-in, all pending invitations for that email are accepted, and the user gets the role set on each one. A user who signs in without an invitation belongs to no organization yet. They are offered to create one.
  • Roles are managed in Popsink. Organizations have admin and user roles, and environments have admin, user and reader. With SSO alone, IdP groups aren’t mapped to Popsink roles. To drive membership and organization roles from your IdP, turn on SCIM provisioning.

​
Removing access

Unassigning a user from the application in your IdP, or disabling them there, blocks their next sign-in. Without SCIM, a session that is already open stays valid until it expires. To cut access immediately, also remove the member from the organization in the Popsink console. With SCIM, deactivation in your IdP revokes open sessions right away (see Deactivating a user).

​
SCIM provisioning

With SSO alone, users are created at their first sign-in, and an organization admin still has to invite each of them. With SCIM 2.0 provisioning, your IdP manages the Popsink users for you:
  • Assigning a user to the Popsink application in your IdP creates their Popsink account and adds them to your organization. No invitation needed.
  • Changing their name or email in your IdP updates it in Popsink.
  • Deactivating or unassigning them in your IdP removes their access to Popsink and signs them out everywhere, at once.
  • IdP groups set their organization role (admin or user).
SCIM sits on top of an SSO connection: set up SSO first. Like SSO, SCIM is set up with the Popsink team. Each SCIM connection is linked to one Popsink organization.

​
Supported identity providers

​
Set up SCIM

1

Request SCIM for your SSO connection

Email support@popsink.com with your Popsink organization name and the IdP groups you want to map to the organization admin role, if any.We turn on SCIM for your connection and send you, over a secure channel:
  • the SCIM endpoint URL (also called the base URL or tenant URL),
  • a bearer token.
The bearer token lets anyone who holds it create and remove users in your organization. Store it in your IdP only. If it leaks, ask us to rotate it.
2

Configure provisioning in your IdP

Enter the endpoint URL and the token in the application you created for SSO. The steps for each IdP are below.
3

Assign users and groups

Assign the users and groups who should have access to Popsink. Your IdP pushes them on its next provisioning cycle. Most IdPs also let you provision one user on demand to test.
4

Map groups to roles

Once your groups have synced at least once, we map them to Popsink organization roles with you. See Group to role mapping.
  1. Open the enterprise application you created for SSO, then go to Provisioning.
  2. Set Provisioning Mode to Automatic.
  3. Under Admin Credentials, paste the SCIM endpoint URL into Tenant URL and the bearer token into Secret Token. Click Test Connection, then Save.
  4. Under Mappings, check that these attributes are mapped: userName, emails[type eq "work"].value, name.givenName, name.familyName and active.
  5. Set Provisioning Status to On and save. Entra runs a cycle about every 40 minutes. Use Provision on demand to test one user right away.

​
Attributes

Attributes that come from your directory are read-only in Popsink. Change them in your IdP.

​
Existing users

If your IdP provisions a user whose email already belongs to a Popsink account (for example, someone who signed in with SSO before you turned on SCIM), the account is linked, not duplicated. It keeps its organizations, its environment access and its history.
Once SCIM is active, only users provisioned by your IdP can sign in through your SSO connection. A user who is assigned to the application but hasn’t been pushed yet can’t sign in. Wait for the next provisioning cycle, or provision them on demand.

​
Group to role mapping

Groups pushed by your IdP can be mapped to the organization roles of the organization linked to the connection:
  • Mappings are ordered. If a user belongs to several mapped groups, the first mapping in the list wins. Put the admin mapping first.
  • A user in no mapped group gets the default user role.
  • Only direct membership counts. Nested groups aren’t supported, and most IdPs reject pushing a group inside another group.
  • An organization role set by a mapping can’t be changed in the Popsink console. Change the user’s groups in your IdP.
Environment roles (admin, user, reader) aren’t driven by SCIM. An organization or environment admin still grants environment access in the console, as described in Users, organizations and roles.

​
Deactivating a user

When your IdP deactivates a user, unassigns them from the application, or deletes them:
  • All their Popsink sessions are revoked immediately. They are signed out of the console and of every data plane.
  • Their membership in the linked organization is removed, with their environment access in that organization.
  • Their Popsink account is kept but can’t sign in, and the resources they created (pipelines, connectors, environments) are left untouched.
If you reactivate the user in your IdP, they get their organization role back through your group mapping. Environment access must be granted again.
Turning SCIM off doesn’t remove anyone: users and roles stay as they are, and you manage them again from the Popsink console. To remove users in bulk, deactivate them in your IdP before turning SCIM off.

​
Self-hosted data planes

On a self-hosted deployment, the data plane has no login of its own. It sends the browser to the control plane, which signs the user in, through your SSO when your domain has it, and returns a short-lived access token to the data plane. SSO covers self-hosted data planes as well, with no extra configuration on the IdP side. For the redirect to come back, Popsink must allowlist the URL of your data plane, for example https://popsink.internal.acme.com. Include it in your SSO request, or send it when you register a new deployment.
A data plane reached through an IP address or a kubectl port-forward can’t receive the SSO redirect. In that case, use the paste-token page at /auth/token-login. See Identity and login for the full flow and the break-glass local account.

​
Troubleshooting

The connection isn’t active for your email domain yet, or you typed an address on a different domain (a subsidiary domain, an alias). Tell us every domain your users sign in with.
The ACS URL / Reply URL or the Entity ID doesn’t exactly match the values we sent you. Check for trailing slashes or http instead of https. Also check that your user is assigned to the application.
Most often, the assertion carries no email or the wrong one, for example a UPN that isn’t a real mailbox. Check the Name ID and the mail attribute. Also check that your IdP’s signing certificate hasn’t been rotated since you sent us the metadata. If it has, send us the new metadata.
SSO signed you in, but nobody has invited your email address to the organization yet. Ask an organization admin to invite you with the exact address your IdP sends.
Your IdP pushes changes on a cycle (about 40 minutes for Entra ID). Use provision on demand to push one user now. If the push fails, check the IdP’s provisioning log: most often the user has no email in emails.
The bearer token is wrong or has been rotated. Paste the token again with no surrounding spaces, or ask us for a new one.
The role is set by your SCIM group mapping. Move the user to another group in your IdP. The change applies on the next provisioning cycle.
Send us the new metadata before the old certificate expires. If your IdP lets you publish both certificates for a while, do it, so that sign-in keeps working during the switch.
For anything else, contact support@popsink.com with the time of the attempt and the email address used. Never send passwords or full SAML responses.