Single Sign-on (SSO)
© 2026 Sonrai Security. All rights reserved.
Overview
Cloud Permissions Firewall (CPF) supports Single Sign-on (SSO) through Auth0. Administrators can configure their own SSO connection using a self-service setup flow, assign role permissions to groups, and optionally enable SCIM provisioning for real-time user lifecycle management.
Supported identity providers:
- Microsoft Entra ID (formerly Azure AD)
- Google Workspace
- Custom SAML
- Custom OIDC
What you can do:
- Enable & Configure SSO when required
- Assign CPF roles to groups instead of individual users
- Allow users to log in without sending an invitation, based on IdP group memberships & CPF permission assignments
- Provision and deprovision users in real time through SCIM
Reference: See Auth0's enterprise connections documentation for the full list of supported providers and protocol-level details.
SSO Requirements
Service Provider (SP) Initiated Logins Only
CPF supports SP-initiated authentication only. Users must navigate to https://app.sonraisecurity.com/ to start a login, and are then redirected to your IdP for authentication.
Granular control of identities via SSO is also available through AWS Identity Center. IdP-initiated sessions — such as launching an application icon from Azure Apps or Okta — are not supported.
Valid Email Addresses
A valid email address is required in the login session under a claim named email. This is generally a standard field, but your SSO configuration should ensure it is included.
Users added or invited to CPF are identified by their corporate email address. The email claim from your IdP must match the address used in the invitation (when an invitation was sent).
IdP Group Synchronization
To map your identity provider's groups into CPF, include a groups claim in your IdP configuration — this makes your IdP groups visible in CPF and lets you assign role permissions to them. If you enable SCIM provisioning, groups are automatically synchronized from your IdP to CPF instead.
If you do not include the groups claim or enable SCIM, only CPF-managed groups (created directly in CPF) are used. See Groups for how to create and manage groups directly in CPF.
When new IdP groups are detected by CPF but have not yet been mapped to CPF, a counter is shown on the button, to indicate new groups are available for mapping.
Setting up Self-Service SSO
The self-service flow uses Auth0's SSO Setup Assistant. Your admin can generate a one-time setup URL by clicking "Configure SSO" on the Users screen, then complete the rest of the configuration directly in their IdP.
How it works
- Your admin opens the Manage / Users area, selects "Configure SSO" and completes the Auth0 SSO Setup Assistant — selecting an IdP, creating the app in the IdP, and configuring token claims.
- Your admin tests the connection.
- (Optional) Your admin enables SCIM provisioning.
If you run into issues during setup, contact Sonrai Support. Support can regenerate the setup URL, troubleshoot connection errors, and reissue SCIM tokens.
Run the SSO Setup Assistant
-
Log into CPF
-
Select Manage / Users and select the Configure SSO button.
-
Select your identity provider — Microsoft Entra ID, Google Workspace, Custom SAML, or Custom OIDC.
-
Create the application in your IdP — the Setup Assistant displays the callback URL, entity ID, and any other values you need to register the application in your IdP. Copy these into your IdP's new application form.
-
Return the client ID and client secret to the Setup Assistant, along with your IdP domain.
-
Configure token claims in your IdP to include:
email(required)groups(required, if you want to use your IdP groups in CPF)
-
Grant your users access to the application in your IdP.
-
Test the connection in the Setup Assistant.
Once the test passes, the enterprise connection is active. Users in the configured email domain(s) are now redirected to your IdP for authentication.
If groups configured in your IdP do not show up, click Finish Setup in the CPF UI, then run the test again.
Identity Provider-Specific Guidance
Microsoft Entra ID (Azure AD)
When configuring the application in Microsoft Entra ID, set the group claim as follows:
- In your Entra application, navigate to Token configuration → Add groups claim.
- For Claim name, enter
groups. - For the source, use
user.groups. - For Which groups associated with the user should be returned in the claim?, select Groups assigned to the application. This makes Cloud-only group display name available as the Source attribute — required for CPF to match group names.
- Leave the Advanced options and Advanced settings sections empty — neither is required.
Google Workspace, Custom SAML, and Custom OIDC
The Auth0 SSO Setup Assistant guides you through the provider-specific fields for each of these IdPs. The general flow is the same as Entra ID:
- Register a new application in your IdP using the values the Setup Assistant displays (callback URL, entity ID, etc.).
- Configure the IdP to include
emailandgroupsclaims in the token. - Return the client ID and secret to the Setup Assistant.
- Test the connection.
Reference: For provider-specific details — for example, where to configure claims in Google Workspace SAML apps — see Auth0's enterprise identity provider documentation.
Group Synchronization
For an overview of CPF-managed vs. IdP-synced groups, and how to create, edit, and assign roles to a group, see Groups in the User Management documentation.
Group name resolution
Group names are the primary identifier and are matched case-sensitively.
- If a CPF-managed group already exists with the same name as a group in your IdP, the existing CPF-managed group is overwritten, and IdP members are placed into the group. Existing role assignments on the group are maintained.
- If no group exists yet, CPF creates a new IdP-synced group on the user's first login.
- You cannot create a CPF-managed group with the same name as an existing IdP-synced group. Either rename the IdP group or remove the IdP-synced group from CPF first.
- If you later enable SCIM integration, groups are automatically synchronized from your IdP to CPF. SCIM creates IdP-synced groups for the groups it provisions and keeps their memberships in sync.
Login without invitations
When SSO is configured and your IdP sends a groups claim, new users no longer require an invitation to log in:
- On first login, if any of the user's IdP groups have role assignments in CPF, the user is auto-created in CPF and granted the group's permissions.
- If the user has no direct role assignments and none of their groups have role assignments in CPF, they are redirected back to the login page.
This makes it possible to onboard new team members entirely through your IdP — add a user to the right group in your IdP, and the next time they sign in to CPF, their access is provisioned automatically.
For login without invitations to work, the groups claim must be configured in your IdP token (see IdP Group Synchronization above). If the claim is missing, return to the Auth0 SSO Setup Assistant and add it.
SCIM Provisioning (Optional)
SCIM (System for Cross-domain Identity Management) lets your IdP push real-time user and group lifecycle events to CPF — create, update, and delete — without waiting for the user to log in.
SCIM is optional. If you skip SCIM but configure the groups claim, group memberships are still discovered when each user logs in.
What SCIM handles
SCIM supports full user & group provisioning and deprovisioning. The following table summarizes the events SCIM handles and how CPF responds:
| Event | What CPF does |
|---|---|
| User created in IdP | CPF creates the user record. If the user is assigned to groups in CPF that have role assignments, an SSO invite email is sent. |
| User updated in IdP | CPF updates the user's attributes and group memberships. New IdP groups are discovered as IdP-synced groups in CPF. |
| User deleted in IdP | CPF removes the user and their group memberships. |
| Group created in IdP | CPF creates a matching IdP-synced group. Assign it a role to grant its members permissions. |
| Group updated in IdP | CPF syncs changes to the group, including its membership. Existing role assignments on the group are preserved. |
| Group deleted in IdP | CPF removes the IdP-synced group. Its members remain in CPF but lose any permissions granted through the group. |
Enable SCIM
- In your IdP, create a SCIM provisioning application.
- Enter the SCIM endpoint URL and bearer token from CPF's SSO settings into your IdP application.
- Map attributes per RFC 7643, including the multi-valued
groupsattribute. - Enable SCIM sync.
Reference: See Auth0's SCIM configuration documentation for IdP-specific attribute mapping details.
For identity provider-specific requirements and detailed attribute mappings, see SCIM - Advanced.
Disable SCIM
To stop SCIM provisioning, you can disable the SCIM integration in Manage / Users.
Inviting Users when SSO is Configured
You can still invite users from the CPF UI when SSO is enabled. Behavior depends on whether the invited user's email domain is configured for SSO.
| Invite scenario | What happens |
|---|---|
| SSO-configured domain — the invited user's email domain is configured for SSO | A placeholder user is created in CPF with the role assignments you specified. An SSO invite email is sent. The user's account is fully populated on their first SSO login. |
| Non-SSO-configured domain — the invited user's email domain is not configured for SSO | The existing invite flow runs. The user is created in Auth0 with the assigned roles. On first login, the invite is converted to a CPF user. |
| SCIM-provisioned user | The IdP sends a user created event, and the user is provisioned in CPF. |
You can mix SSO and non-SSO users in the same CPF tenant. SSO is enforced per email domain — for example, users at @yourcompany.com go through SSO while contractor accounts at other domains continue to use local authentication.
SSO Connection Reference
Most settings are populated automatically by the Auth0 SSO Setup Assistant. The values below are useful when filling in the IdP-side configuration or troubleshooting.
| Setting Name | Value/Description |
|---|---|
| SSO Connection Name | The convention is "cpfTenantID-sso". Example: crc13294495-sso |
| Entity ID | urn:auth0:sonraisecurity:crc13294495-sso |
| Assertion Consumer Service Callback URL | https://login.sonraisecurity.com/login/callback?connection=crc13294495-sso |
| SSO Signing Certificate | Outgoing authentication requests are signed by this certificate. |
Common SSO Configuration Questions
Q: Does CPF support Service Provider (SP) initiated SSO, Identity Provider (IdP) initiated SSO, or both?
A: Only SP-initiated logins are supported.
Q: Does CPF support automatic SAML metadata updates?
A: No, SAML metadata updates are not supported.
Q: What is the application session time?
A: The idle session timeout is 15 minutes for both locally and SSO-authenticated users.
Q: What is the Sign-on URL?
A: The Sign-on URL is https://app.sonraisecurity.com/
Q: Can non-email-enabled addresses be used?
A: No. Only valid addresses that can receive email are supported.
Q: What signing certificate is used for outgoing requests?
A: Outgoing authentication requests are signed by this certificate.
Q: What algorithms are used in outgoing SSO requests?
A:
- Sign Request Algorithm is
RSA-SHA256 - Sign Request Algorithm Digest is
SHA256
Q: Is the Assertion Consumer Service (ACS) URL included in the sign-on request?
A: No. The Entity ID is included in the request and is associated with the appropriate ACS URL in the IdP configuration.
Q: What is the URL for CPF's SP login authentication platform?
A: The base URL is https://login.sonraisecurity.com/login/callback
Tenant-specific ACS URLs include the Entity ID, e.g. https://login.sonraisecurity.com/login/callback?connection=crc13294495-sso
Q: Will SAML requests be sent with a REDIRECT or POST binding?
A: Both HTTP-Redirect and HTTP-POST request bindings are available. The default is HTTP-POST.
Q: If SSO is in use, is CPF's own MFA still in effect?
A: When SSO is enabled, CPF's internal MFA is disabled and all authentication — including password requirements and MFA — is managed by your SSO service.
Q: Can SSO users bypass SSO with local authentication?
A: No. SSO is enforced by email domain. When a domain is configured for SSO, all users on that domain must authenticate through SSO; local authentication is unavailable. If your SSO platform is down, contact Sonrai Support to temporarily disable SSO.
Q: We are using Okta for our SSO IdP, but after adding the email attribute we still cannot log in. Why?
A: Okta supports adding attributes via either Profile Editor or SAML Integration / Attribute Statements. You must use SAML Integration / Attribute Statements for the email field — Profile Editor does not properly encode the attribute.
Q: My users belong to IdP groups, but their group permissions are not being applied. What should I check?
A: Verify that your IdP token includes a groups claim and that the group names in your IdP match the group names assigned roles in CPF (matching is case-sensitive). For Entra ID, also confirm Cloud-only group display name is the source attribute on the groups claim.