Single Sign-On (SSO): Complete Setup Guide

Single sign-on (SSO) lets your team sign in to Plenix with the account they already use for work, such as Microsoft 365, Google Workspace or Okta. They click Sign in with Microsoft (or whatever you call the button) on your Plenix login page, sign in with their identity provider, and arrive in Plenix.

Who can set it up: an administrator of your Plenix workspace. Plan: Business and Enterprise. Time needed: about 15 minutes, plus access to your identity provider's admin console.

Password sign-in keeps working alongside SSO. If your identity provider is ever unavailable, your administrators can still get in.

Before you start

You need:

1. Admin access to Plenix. You need to be able to open Settings → SSO.
2. Admin access to your identity provider. For example, the Microsoft Entra admin centre, the Google Admin console or the Okta admin dashboard. If someone else looks after it, send them this page and the details from step 1 below.
3. A decision on the protocol. Plenix supports both:
   • OpenID Connect (OIDC) is the simplest. Choose it for Microsoft Entra ID and Okta.
   • SAML 2.0 works with almost every provider. Choose it for Google Workspace, or if your IT policy requires SAML.

Not sure which to pick? Use OIDC for Microsoft and Okta, and SAML for Google Workspace.

Step-by-step pages with screenshots-in-words for each provider:

• Microsoft Entra ID (Azure AD)
• Google Workspace
• Okta

The rest of this page works for any provider.

Step 1: Get the details your identity provider needs

1. In Plenix, go to Settings → SSO.
2. The Details for your identity provider card shows four values. Each one has a copy button.

Plenix field	What your provider may call it	Used for
Redirect URI (web platform)	Redirect URI, Callback URL, Sign-in redirect URI	OIDC
Assertion Consumer Service (Reply) URL	ACS URL, Reply URL, Single sign-on URL	SAML
Entity ID (Identifier / Audience)	Identifier, Audience URI, SP Entity ID	SAML
Service provider metadata	SP metadata URL	SAML (optional, if your provider can import it)

Each value is specific to your workspace and includes your workspace address. Copy it exactly. Don't type it out.

Step 2: Create the app in your identity provider

The menu names differ between providers, but the job is always the same.

For OIDC:

1. Create a new web application (sometimes called an app registration or an OIDC client).
2. Add the Redirect URI from Plenix as an allowed redirect URI of type Web.
3. Make sure the app may use the scopes openid, email and profile.
4. Create a client secret. Copy the secret value straight away, because most providers only show it once.
5. Note the Client ID and the Issuer URL. The issuer is the base address of your provider's sign-in service.

For SAML:

1. Create a new SAML application.
2. Set the ACS / Reply URL and the Entity ID / Audience to the values from Plenix.
3. Set the Name ID to the user's email address, in the EmailAddress format.
4. Make sure the provider signs the assertion. Plenix rejects unsigned assertions.
5. Copy the provider's metadata URL. If your provider doesn't offer one, copy its sign-on URL and download its signing certificate instead.

For both: assign the app to the people (or groups) who should be able to use it. Many providers block sign-in for people who are not assigned.

Step 3: Connect the provider in Plenix

1. In Settings → SSO, click Connect identity provider.
2. Under Protocol, choose OpenID Connect or SAML 2.0.
3. Enter a Button label, for example Microsoft or Google. The login page shows it as Sign in with Microsoft.
4. Fill in the details from step 2:
   • OIDC: Issuer URL, Client ID, Client secret.
   • SAML: IdP metadata URL (best, because Plenix then picks up certificate changes for you). If you don't have one, fill in Sign-on URL (if no metadata URL) and paste the certificate into Signing certificate (if no metadata URL). You can also enter IdP entity ID / issuer (optional).
5. Leave Enable single sign-on off for now. You'll switch it on once the settings below are right.
6. Click Save.

Later, when you edit the connection, leave Client secret or Signing certificate blank to keep the one already saved.

Step 4: Choose who can sign in

Three settings decide who gets in:

• Allowed email domains. Enter your company's email domains, separated by commas, for example acme.com, acme.co.uk. Only addresses on these domains can sign in with SSO. Leave it empty to accept any address that already has a Plenix account.
• Auto-provision new users. Off by default. While it's off, SSO only signs people in to Plenix accounts that already exist with the same email address. Invite people first in Settings → Users. Turn it on to have Plenix create the account automatically the first time someone from an allowed domain signs in. This needs at least one allowed domain.
• Access role for new users. The role an auto-provisioned person gets (Viewer unless you change it). Administrator roles can't be picked here. Promote people afterwards in Settings → Users.

Each auto-provisioned person uses a user seat on your plan. When the seats run out, the next new person sees a message telling them to ask an administrator.

Plenix matches people by email address, so make sure the email your provider sends is the same one the person uses in Plenix. Capital letters don't matter.

Step 5: Decide on two-factor authentication

Also require Plenix two-factor is on by default. After signing in with the identity provider, people also complete Plenix two-factor, or set it up the first time. The status shows Plenix MFA required.

If your identity provider already makes people use MFA for this app (for example a Microsoft Conditional Access policy), you can turn it off. The status then shows IdP handles MFA. If you're not sure, leave it on.

Step 6: Switch it on and test

1. Switch on Enable single sign-on and click Save.
2. Open a private / incognito browser window and go to your workspace login page (https://<your-workspace>.plenix.cloud/tenant-login).
3. Click Sign in with …, sign in with your identity provider, and complete two-factor if asked.
4. You should land on your Plenix dashboard.
5. Back in Settings → SSO, the card now shows Last SSO sign-in with the time.

If it didn't work, the card shows Last failed sign-in with the reason. See Rolling Out SSO and Fixing Sign-In Problems.

Step 7: Tell your team

Send your team the workspace login address and tell them to use the Sign in with … button. Their password still works, but they won't need it.

Good to know

• Sign-in starts from Plenix. People must start from the Plenix login page. Clicking a Plenix tile in your provider's app launcher (IdP-initiated sign-in) isn't supported yet.
• Roles aren't synced from groups. Your provider decides who can sign in. Plenix roles are still managed in Settings → Users.
• Leavers. Disabling someone in your identity provider stops SSO sign-in straight away. Also deactivate them in Settings → Users, because their Plenix password would otherwise still work.
• Everything is audited. Every SSO sign-in and every auto-created account is recorded in the audit log.
• Removing SSO. Click the remove button on the SSO card. Everyone goes back to signing in with their Plenix password.

For your IT team

• OIDC: authorization code flow with PKCE and a nonce; scopes openid email profile. Issuer discovery is used, and the issuer in the tokens must exactly match the configured Issuer URL. Email is read from email, then preferred_username, then upn. A token with email_verified: false is refused. Multi-tenant endpoints such as Entra common / organizations aren't accepted; use your own tenant ID.
• SAML: SP-initiated only. The assertion must be signed; the outer response may be unsigned. NameID format urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. If NameID isn't an email, Plenix looks for an email attribute (email, mail, emailAddress, the standard …/claims/emailaddress claim or urn:oid:0.9.2342.19200300.100.1.3). First and last name come from givenName / surname style attributes when present.
• Metadata and discovery URLs must be HTTPS and reachable from the internet.
• Client secrets and certificates are stored encrypted.

Where to go next

• The full setup guide → Single Sign-On (SSO): Complete Setup Guide
• SSO with Microsoft Entra ID (Azure AD)
• SSO with Google Workspace
• SSO with Okta
• Rolling Out SSO and Fixing Sign-In Problems
• See where this fits in the bigger picture → Integrations Overview — What You Can Connect