SSO — OIDC and SAML

Federated SSO: per-organization OIDC (Shared Model) and domain-wide SAML (Enterprise Model) — configuration, flow, and account rules

Differs depending on the model

Shared Model (SaaS): SSO via OIDC, configured per organization (tenant) on its own subdomain. Each organization can allow email/password + SSO or SSO only. Enterprise Model (Dedicated): SSO via SAML, a single configuration for the client's main domain. Email/password authentication remains available for external accounts; access to organizations is managed internally through roles.

Local authentication (email + password), 2FA, and account lockout are covered in Local Authentication and 2FA.

Overview

SSM.ro supports federated Single Sign-On (SSO) authentication, with a different protocol depending on the deployment model:

Shared Model (SaaS) — OIDC (OpenID Connect), configured at the organization (tenant) level. Each organization has its own *.appssm.ro subdomain and its own OIDC configuration. SSO is optional: an organization can allow both local authentication (email/password) and SSO, or enforce SSO only.
Enterprise Model (Dedicated) — SAML, a single configuration for the client's main domain (clientdomain.ext). Local authentication (email/password) remains available for external accounts that are not part of the identity provider. The dedicated installation can host one or more organizations (on subdomains), and access to each organization is controlled internally through roles.

In both models, the identity provider (IdP) is external and administered by the client organization.

Supported Identity Providers

OIDC (Shared Model)

SSM.ro is compatible with any standard-compliant OIDC IdP, including:

Microsoft Entra ID (Azure AD)
Okta
Google Workspace
Keycloak
Any other OIDC provider compliant with the OpenID Connect Core specification

SAML (Enterprise Model)

SSM.ro is compatible with any SAML 2.0-compliant IdP, including:

Microsoft Entra ID (Azure AD) — SAML
Okta — SAML
Active Directory Federation Services (AD FS)
Keycloak — SAML
Any other provider compliant with the SAML 2.0 specification

Configuration Parameters

OIDC — per organization (Shared Model)

Parameter	Description
Name	Label displayed to users on the authentication button
Client ID	The identifier of the application registered with the IdP
Client Secret	The application secret generated by the IdP
Issuer URL	The IdP's OIDC discovery URL (e.g. `https://login.microsoftonline.com/{tenant-id}/v2.0`)
Allowed domains	List of authorized email domains (e.g. `companie.ro`) — accounts with other domains are rejected

SAML — on the main domain (Enterprise Model)

Parameter	Provided by	Description
SP Entity ID	SSM.ro	The identifier of the Service Provider (the SSM.ro application)
ACS URL	SSM.ro	Assertion Consumer Service — the endpoint where the IdP sends the SAML response
IdP SSO URL	Client	The identity provider's SignOn endpoint
IdP Entity ID (Issuer)	Client	The identifier of the identity provider
X.509 signing certificate	Client	The public certificate used to validate the signature of SAML assertions
NameID / email mapping	Client	The attribute that identifies the user (e.g. the email address)

Redirect URI / ACS

OIDC Callback (Shared Model)

When registering the SSM.ro application with the IdP, the redirect URI must be configured as:

https://{subdomain}.appssm.ro/accounts/auth/oidc/callback?pid={sso_provider_id}

{subdomain} — the SSM.ro organization's subdomain
{sso_provider_id} — the internal identifier of the SSO provider, provided by SSM.ro during configuration

SAML ACS URL (Enterprise Model)

When registering the SSM.ro application with the SAML IdP, the ACS URL is configured on the client's domain (illustrative path):

https://clientdomain.ext/accounts/auth/saml/callback

Authentication Modes

Mode	Model	Description
email/password + SSO	Shared (per organization)	Users can choose between SSO (OIDC) and local authentication (email + password)
SSO only	Shared (per organization)	The only mode allowed for that organization; local authentication is disabled
SAML + email/password (external accounts)	Enterprise	SAML on the main domain for organization users; email/password remains available for external accounts

OIDC Authentication Flow (Shared Model)

1. The user accesses SSM.ro and selects "Sign in with SSO"
       │
       ▼
2. SSM.ro redirects the user to the configured IdP
   (authorization endpoint + scope: openid, profile, email)
       │
       ▼
3. The user authenticates with the IdP (organization credentials, IdP-level MFA if configured)
       │
       ▼
4. The IdP redirects back to SSM.ro with the authorization code
   (callback URI: https://{subdomain}.appssm.ro/accounts/auth/oidc/callback?pid=...)
       │
       ▼
5. SSM.ro exchanges the authorization code for tokens (ID token + access token)
   via back-channel HTTPS (client_id + client_secret)
       │
       ▼
6. SSM.ro validates the ID token (signature, issuer, audience, expiry)
   and checks the email domain against the list of allowed domains
       │
       ▼
7. SSM.ro session created — the user is authenticated

SAML Authentication Flow (Enterprise Model)

1. The user accesses SSM.ro on the client's domain and selects "Sign in with SSO"
       │
       ▼
2. SSM.ro (Service Provider) generates a SAML request (AuthnRequest)
   and redirects the user to the IdP SSO URL
       │
       ▼
3. The user authenticates with the IdP (organization credentials, IdP-level MFA if configured)
       │
       ▼
4. The IdP sends back a SAMLResponse (signed assertion) to the ACS URL
   (https://clientdomain.ext/accounts/auth/saml/callback)
       │
       ▼
5. SSM.ro validates the assertion's signature with the IdP's X.509 certificate
   (issuer, audience, validity conditions, NameID)
       │
       ▼
6. SSM.ro session created — access to organizations is granted according to the user's roles

Account Rules

Rule	Behavior
Domain restriction (OIDC)	Accounts with an unauthorized email domain are rejected — access is not granted
Automatic provisioning	An SSM.ro account is automatically created on the first successful SSO authentication, if one doesn't already exist
SSO lock	In SSO-only mode (Shared), an organization's users cannot reset their local password and access the platform only through the IdP
External accounts (Enterprise)	External accounts that are not part of the SAML IdP can still use email/password
Existing accounts	Existing local accounts with the same email are linked to the SSO identity on the first SSO authentication
Multiple providers (OIDC)	An organization in the Shared model can configure several OIDC providers simultaneously (e.g. one IdP for employees, another for partners)
Organization access (Enterprise)	Access to each organization in the dedicated installation is controlled internally through roles (RBAC)

Responsibilities

Responsibility	SSM.ro	Client
Configuring the SSO provider (OIDC or SAML) in the platform	Yes	—
Registering the SSM.ro application with the IdP	—	Yes
Managing users and access policies in the IdP	—	Yes
IdP availability	—	Yes (organization's SLA)
Auditing SSM.ro sessions	Yes	—

Security Notes

SSO provider secrets (Client Secret for OIDC; the signing certificate for SAML) are stored encrypted — they are not exposed in the interface after configuration
SSM.ro does not store the user's password in the case of SSO authentication
SSM.ro sessions time out after 30 minutes of inactivity, regardless of the active session at the IdP (see Sessions)
Upon logging out of SSM.ro, the local session is terminated; logging out of the IdP is the client's responsibility

SSO — OIDC and SAML

On this page