SSO / SAML Authentication

Configure Single Sign-On with your organization's identity provider for secure, centralized access to Et'al MDM.

Et'al MDM supports SAML 2.0 Single Sign-On across all plans, allowing your team to authenticate using your organization's existing identity provider.

Supported Identity Providers

Et'al MDM works with any SAML 2.0 compliant identity provider, including:

Okta
Microsoft Azure AD (Entra ID)
Google Workspace
OneLogin
JumpCloud
Ping Identity
Any SAML 2.0 IdP

How It Works

Your team visits etalmdm.com/login and selects the SSO (SAML) tab
They enter their work email (e.g., jane@yourcompany.com)
Et'al MDM detects the email domain and redirects to your identity provider
The user authenticates with their corporate credentials (password, MFA, etc.)
Your IdP redirects back to Et'al MDM with a verified identity
The user is signed in — no separate password needed

Setting Up SSO for Your Organization

To configure SSO, your IT administrator needs to create a SAML 2.0 application in your identity provider using the following values:

Et'al MDM SAML Configuration

Field	Value
Entity ID / Metadata URL	`https://api.etalmdm.com/auth/v1/sso/saml/metadata`
ACS URL (Assertion Consumer Service)	`https://api.etalmdm.com/auth/v1/sso/saml/acs`
NameID Format	`emailAddress` or `persistent`
Sign-on URL	`https://etalmdm.com/login`

You can download our SAML metadata XML directly: Download Metadata

Required SAML Attributes

Your identity provider must include the user's email address in the SAML assertion. Et'al MDM checks these attribute names in order:

urn:oid:0.9.2342.19200300.100.1.3
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
mail
email

Most identity providers include email by default. If authentication fails, verify this attribute is mapped.

Optional Attributes

For a richer user profile, you can also map:

Attribute	Purpose
`givenName` or `first_name`	User's first name
`sn` or `last_name`	User's last name
`displayName`	Full display name

Setup Guides by Provider

Okta

In Okta Admin Console, go to Applications → Create App Integration
Select SAML 2.0 and click Next
Configure:
- Single sign-on URL: https://api.etalmdm.com/auth/v1/sso/saml/acs
- Audience URI (SP Entity ID): https://api.etalmdm.com/auth/v1/sso/saml/metadata
- Name ID format: EmailAddress
Add attribute statements for email, firstName, lastName
Assign the app to the appropriate users/groups
Copy the Metadata URL from the app's Sign On tab
Send the Metadata URL to Et'al MDM support to complete the connection

Microsoft Azure AD (Entra ID)

In Azure Portal, go to Enterprise Applications → New Application
Click Create your own application → name it "Et'al MDM"
Go to Single sign-on → SAML
In Basic SAML Configuration:
- Identifier (Entity ID): https://api.etalmdm.com/auth/v1/sso/saml/metadata
- Reply URL (ACS URL): https://api.etalmdm.com/auth/v1/sso/saml/acs
In Attributes & Claims, ensure emailaddress is mapped
Assign users/groups to the application
Copy the App Federation Metadata URL from the SAML Signing Certificate section
Send the Metadata URL to Et'al MDM support to complete the connection

Google Workspace

In Google Admin Console, go to Apps → Web and mobile apps → Add app → Add custom SAML app
Name it "Et'al MDM" and click Continue
Copy the SSO URL and Certificate (or download the metadata)
Configure the Service Provider:
- ACS URL: https://api.etalmdm.com/auth/v1/sso/saml/acs
- Entity ID: https://api.etalmdm.com/auth/v1/sso/saml/metadata
- Name ID format: EMAIL
Map attributes: email → Primary email
Enable the app for the appropriate organizational units
Send the metadata to Et'al MDM support to complete the connection

Completing the Setup

After configuring your identity provider:

Send your IdP Metadata URL (preferred) or Metadata XML file to support@etalmdm.com
Include the email domain(s) to associate (e.g., yourcompany.com)
We'll register the connection and confirm within 24 hours
Test by logging in at etalmdm.com/login → SSO (SAML) tab

Important: SSO users and password users with the same email address are treated as separate accounts. If your organization uses SSO, we recommend all users sign in via SSO exclusively.