Microsoft Azure Entra ID SSO Setup
Prerequisites
Before starting, confirm that:
The customer has Microsoft Azure / Entra admin access.
The Neeve organization exists.
Users who need access exist in Entra ID.
Users who need access are also invited or created in Neeve Portal.
The customer knows which domain should be routed through SSO.
Step 1: Add an SSO Provider in Neeve Portal
Log in to Neeve Portal as an organization admin.
Go to Settings.
Select Configure Org.
Open Security and Authentication.
Click Add Provider.
Enter a provider name.
Example:
Microsoft Entra ID
Leave the provider type as Custom.
Current behavior: Neeve uses a generic Custom provider option. Future versions may include provider-specific selections for Entra ID.
Step 2: Select SAML Configuration
Continue to the SSO configuration screen.
Confirm that the protocol is SAML.
Neeve Portal automatically generates:
ACS URL Entity ID URL
Copy both values.
These values are required in Entra ID.
Step 3: Create or Configure the Enterprise Application in Entra ID
Log in to the Microsoft Entra Admin Center.
Go to:
Identity > Applications > Enterprise applications
Create or open the Neeve application.
Select Single sign-on.
Choose SAML.
Step 4: Enter Neeve SAML Values in Entra ID
In the SAML configuration section, enter the values from Neeve Portal.
Entra ID Field | Neeve Value |
|---|---|
Reply URL / ACS URL | ACS URL from Neeve Portal |
Identifier / Entity ID | Entity ID URL from Neeve Portal |
Save the configuration.
Step 5: Configure Claims and Attributes
Neeve currently supports the email attribute for SAML mapping.
Configure the Entra ID claim that represents the user’s primary email address.
The attribute sent to Neeve must match the Neeve Portal email attribute exactly.
Recommended app attribute:
email
This is case-sensitive.
Correct:
email
Incorrect examples:
Email EMAIL mail user.mail
Use the customer’s Entra configuration to map the correct user email value into the SAML attribute named email.
Step 6: Assign Users or Groups in Entra ID
In the Enterprise Application, go to Users and groups.
Assign the users or groups that should have access to Neeve.
Confirm the users also exist in Neeve Portal.
Entra ID authenticates the user. Neeve Portal authorizes access.
Step 7: Provide Entra Metadata to Neeve Portal
Entra ID supports both:
Metadata XML upload Metadata URL
Use whichever option is available in the Neeve Portal configuration.
Recommended option:
Download the federation metadata XML from Entra ID.
Upload it into Neeve Portal.
Alternative option, if enabled:
Copy the Entra metadata URL.
Paste it into Neeve Portal.
Step 8: Map the Email Attribute in Neeve Portal
Return to Neeve Portal.
In the attribute mapping section, set the email attribute to match the Entra ID SAML claim.
Recommended:
email
This must exactly match the claim name sent by Entra ID.
Step 9: Add the Domain Representation
Add the customer domain that should use Entra ID SSO.
Example:
customer-domain.com
Save the configuration as a draft if review is needed.
Step 10: Enable SSO
Review the configuration.
Click Enable.
After enabling SSO:
Users with the configured domain are redirected to Entra ID at next login.
Existing active sessions continue until expiration.
Users are not force-logged out immediately.
Neeve Portal password login is bypassed for SSO users.
Step 11: Test the Login Flow
Open an incognito or private browser window.
Accept a Neeve Portal invitation as a test user.
Enter the SSO-enabled email address.
Confirm the user is redirected to Microsoft Entra ID.
Authenticate through Entra ID.
Confirm the user lands in Neeve Portal.
Verify expected access.
Review audit and access logs.
Important Notes for Entra ID
MFA
When SSO is enabled, Neeve Portal MFA is automatically disabled for SSO users. MFA should be enforced in Entra ID.
Existing Sessions
Existing Neeve sessions remain active until they naturally expire.
Disabling SSO Limitation
Known limitation:
Users created after SSO is enabled may not have a Neeve Portal password. If SSO is later disabled, those users may not be able to log in with password-based authentication.
Current workaround:
Admin manually re-invites affected users.
Status:
Engineering is working on a patch release and SOP for this scenario.