Rippling SSO and SCIM setup

Overview

This guide walks a Rippling administrator through configuring Rippling as the identity provider for a Fencer organization. Two integrations work together:

• SAML SSO — your team signs in to Fencer through Rippling.
• SCIM provisioning — Rippling automatically creates, updates, and deactivates Fencer user accounts as you add or remove people in Rippling.

You can configure SAML alone if you only need login. Set up SAML before SCIM: provisioned users have no Fencer password and sign in through SAML.

App Shop install

If you installed Fencer from the Rippling App Shop, your team signs in with Rippling straight away, and employees you give access to Fencer in Rippling are added to your organization automatically. There is nothing to set up here. See the Rippling Integration guide for installation, sign-in, access requirements and common questions.

Use the custom-app steps below only when you are not using the App Shop listing.

Prerequisites

• A Rippling administrator account with permission to create custom apps.
• A Fencer organization administrator role.
• A plan that includes single sign-on and SCIM. Without it, the Single Sign-On and User provisioning (SCIM) sections of Settings > Authentication show Upgrade to unlock.

Part 1: SAML SSO setup

The SAML configuration happens in two places: you copy values from Fencer into Rippling’s custom app, then copy Rippling’s metadata URL back into Fencer.

Step 1: Start the connection on the Fencer side

1. In Fencer, navigate to Settings > Authentication and find the Single Sign-On section.
2. Click Configure SSO. In the Add SSO connection dialog, keep SAML 2.0 selected as the Protocol.
3. Note the Service Provider values shown under Service Provider Details:
   • ACS URL — https://app.fencer.dev/accounts/saml/<your-org-uid>/acs/
   • Entity ID — https://app.fencer.dev/accounts/saml/<your-org-uid>/metadata/
   • The SP metadata URL is the same as the Entity ID (it appears as Metadata on the connection card once saved). Rippling can fetch this directly to auto-fill the Service Provider section.

Keep this dialog open. You will return to it in Step 4.

Step 2: Create the SAML app in Rippling

1. In Rippling, go to Apps > Custom Apps > New Custom App and choose SAML as the protocol.
2. Name the app Fencer.
3. Fill out the SAML configuration form using the values below. Anything not listed should be left at its default.

Rippling field	Value
Default NameID format	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Default relay state	Leave blank
Sign response	Checked
SP public key (encrypt assertion)	Leave blank
ACS URL	Paste from Fencer (Step 1)
Entity ID	Paste from Fencer (Step 1)
Metadata URL	Leave blank
Metadata	Leave blank
SessionNotOnOrAfter (days)	1
Certificate Length (bits)	2048
Just In Time Provisioning	Unchecked
Disable Attribute Converters	Unchecked
Supports SP Initiated Flow Only	Unchecked
URL to Trigger SP Initiated login	https://app.fencer.dev/accounts/saml/<your-org-uid>/login/
Use OASIS namespace prefixes	Unchecked
Encrypt Assertion	Unchecked
disable InResponseTo	Unchecked
Signing Algorithm	http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Assertion Digest Algorithm	http://www.w3.org/2001/04/xmlenc#sha256

Caution

Rippling defaults the Assertion Digest Algorithm to SHA-1. Fencer requires SHA-256. If you skip this change, every login will fail with a digest mismatch error.

Note

Fencer does not require encrypted assertions, so leave Encrypt Assertion and SP public key blank. Signed assertions are sufficient.

Step 3: Map SAML attributes in Rippling

In Rippling’s attribute mapping section, configure the following four attributes. Fencer accepts several common attribute names for each, so the exact names below are recommended but not strictly required.

Fencer expects	Rippling source	SAML attribute name
Email	Employee work email	urn:oid:0.9.2342.19200300.100.1.3 or email
First name	Employee first name	urn:oid:2.5.4.42 or firstName
Last name	Employee last name	urn:oid:2.5.4.4 or lastName
Role (optional)	A custom attribute holding the role	https://app.fencer.dev/SAML/Attributes/role — see The role attribute
NameID	Employee work email	The NameID itself, formatted as an email address

Fencer treats the SAML NameID as a fallback for the email attribute, so the NameID must be the user’s email address.

Step 4: Finish the connection on the Fencer side

1. In Rippling, copy the IdP Metadata URL and the IdP entity ID (issuer) from the custom app’s overview page.
2. Return to the Fencer Add SSO connection dialog and keep IdP Configuration Method on Metadata URL.
3. Paste the metadata URL into IdP Metadata URL and the entity ID into IdP Entity ID.
4. Leave Reject IdP-initiated SSO on if your users start from Fencer’s login page. Turn it off if they launch Fencer from the Rippling app launcher.
5. Under Provisioning, keep Just-in-Time provisioning on to let users who are new to Fencer join with the Default role for new users, or turn it off to admit only existing members (invited, or provisioned by SCIM in Part 2). Optionally, restrict it to specific Allowed email domains.
6. Check Enable SSO, leave Enforce SSO off until you have tested, and click Save Configuration.
7. On the connection card, click Test Connection. Fencer redirects you through Rippling. On success, you return to Settings > Authentication with a confirmation banner. On failure, Fencer shows an error page with a diagnostic of what went wrong and a reference ID (for example sso-1a2b3c4d). Share this ID with support@fencer.dev if you need help resolving the issue.

Note

The diagnostic details are only shown during the test flow. Regular sign-in failures show only the reference ID, to avoid leaking configuration details. Test Connection appears once the connection is enabled.

If the test fails, see the Troubleshooting section.

Linking existing users to SSO

After enabling SAML SSO, existing users who were created before SSO was configured need to link their accounts. Fencer does not automatically bind SSO identities to existing accounts by email — each user must explicitly link their SSO identity once.

• For users: A Link your account to SSO banner appears in Fencer for unlinked users. While signed in with their usual method (password or social login), the user clicks Link SSO Account, confirms on the next page, and signs in with Rippling. Once linked, only an administrator can unlink the SSO identity.
• For admins: The Members tab of Admin > Team shows each user’s SSO link status next to their status. Admins can send a reminder email to a user who has not linked yet with Send SSO Linking Reminder in the member’s actions menu.
• New users provisioned via SCIM or created through JIT (just-in-time) provisioning are linked automatically — no action needed.

Caution

Until a user links their SSO identity, they cannot sign in through SSO — even if their email matches. This is a security measure to prevent unauthorized account binding.

Part 2: SCIM provisioning setup

Rippling provisions Fencer accounts using a SCIM 2.0 bearer token. You generate the token in Fencer, then paste it into Rippling’s SCIM connector form.

Step 1: Generate a SCIM token in Fencer

1. In Fencer, navigate to Settings > Authentication and find the User provisioning (SCIM) section.
2. Click Enable SCIM.
3. In the Enable SCIM provisioning dialog, choose the Default role for provisioned users and click Enable SCIM.
4. Fencer displays the SCIM Bearer Token once. Copy it now — you will not be able to see it again. If you lose it, you can rotate to a new token from the same section.
5. Note the SCIM Base URL shown below the token: https://app.fencer.dev/scim/v2. Click Done when you have copied both.

Step 2: Configure Rippling’s SCIM connector

In the Fencer custom app you created in Part 1, open the SCIM Provisioning tab and fill out the form using the values below.

Rippling field	Value
SCIM version	2.0
Does not support One Way Sync	Off — Fencer supports one-way sync from Rippling
SCIM base URL	https://app.fencer.dev/scim/v2
SCIM authorization method	Bearer Token (paste the token from Step 1)
Supports groups	Unchecked, unless you manage Fencer roles with SCIM role groups
Supports pagination	Checked
Create & Delete Groups	N/A (groups disabled)
Use PATCH to edit Groups	N/A (groups disabled)
Generate temporary password	Unchecked — Fencer users authenticate via SAML, not passwords
Username to use for account creation	Use email address as username
Supported SCIM Attributes	externalId, emails.primary, name.givenName, name.familyName, displayName

Caution

Do not select name.formatted. Fencer does not return that attribute, and selecting it can cause Rippling to flag every synced user as having missing data.

What Rippling can sync

Fencer’s SCIM endpoint supports the following operations:

• Create user — Rippling adds a new user to your Fencer organization. The user is immediately active and can sign in through SAML SSO. If the user was previously deactivated, this reactivates the existing account instead of failing.
• Update user — Name and other profile fields are kept in sync via PUT.
• Deactivate user — Removing or offboarding the user in Rippling removes them from your Fencer organization. The SCIM mapping is preserved so the user can be reactivated later. Use this for standard offboarding.
• Reactivate user — Re-adding the user in Rippling restores their Fencer membership.
• Delete user — Removes the user from your Fencer organization and deletes their SCIM mapping. After a delete, the user cannot be reactivated via PATCH — Rippling must re-provision them as a new user.
• Filter users by userName or externalId (equality only).

The following SCIM features are not supported by Fencer:

• Sort, ETag, bulk operations, or password change endpoints.
• User PATCH supports only replace operations on the active attribute and the SCIM role attribute — unsupported operations are rejected with a 400 error. Rippling automatically falls back to PUT for attribute changes, so this rarely matters in practice.

Token rotation

If your bearer token is compromised or you simply want to rotate credentials:

1. In Fencer, navigate to Settings > Authentication and find User provisioning (SCIM).
2. Click Rotate Token.
3. Copy the new token immediately — the old one stops working as soon as you rotate.
4. Update the bearer token in Rippling’s SCIM connector form. The next sync will use the new token.

Troubleshooting

• “Invalid SAML response” or digest mismatch errors after Test Connection. Open the Rippling custom app and verify that the Assertion Digest Algorithm is set to http://www.w3.org/2001/04/xmlenc#sha256 (not the default SHA-1).

• “Client not found” or unknown service provider errors. The ACS URL or Entity ID in Rippling does not match what Fencer expects. Confirm that both URLs include your organization’s UID exactly as shown under Service Provider Details in Fencer.

• “401 Unauthorized” on every SCIM sync. The bearer token is wrong or expired. Verify that Rippling is sending the token using the Bearer Token authorization method (not generic “Token”). If unsure, rotate the token in Fencer and paste the new value into Rippling.

• Synced users appear as having missing data in Rippling. You probably selected name.formatted in the supported attributes list. Remove it — Fencer does not return that field.

• “Email domain not allowed for SSO” when a SAML user tries to sign in. The connection has an Allowed email domains restriction that excludes the user’s domain. Either add the domain to the allow list, or pre-provision the user via SCIM so JIT is bypassed.

• A user deactivated in Rippling can still sign in to Fencer. Confirm that the SCIM connector is configured to send PATCH requests when employees are offboarded. Fencer honors PATCH active=false to deactivate accounts.

• “SSO identifier does not match a linked account.” The user exists in Fencer but has not linked their SSO identity. They need to complete the SSO linking flow — a Link your account to SSO banner guides them through it. Admins can also send a linking reminder from Admin > Team.

• A sign-in or test shows a reference ID (e.g. sso-1a2b3c4d). Note this ID and share it with support@fencer.dev along with a description of what you configured. The ID helps the support team locate the exact failure in the logs.

Related pages

• SSO and Authentication
• Team and Member Management
• Roles and Permissions