Enterprise SSO per Organizzazione

L’Enterprise Single Sign-On (SSO) consente a ciascuna organizzazione in Auris di delegare l’autenticazione al proprio identity provider aziendale. Quando un utente esegue il login con un indirizzo email appartenente a un dominio verificato, Auris lo reindirizza automaticamente all’IdP della sua organizzazione invece di presentare il modulo standard di username/password. Dopo l’autenticazione riuscita all’IdP, l’utente viene restituito ad Auris e viene associato a un account esistente o viene eseguito il provisioning automatico tramite creazione JIT (Just-in-Time).

Questa funzionalità è progettata per prodotti SaaS B2B dove i clienti enterprise richiedono che i propri dipendenti si autentichino esclusivamente tramite credenziali gestite dall’azienda.

Protocolli Supportati

Auris supporta due protocolli SSO, entrambi implementati tramite la funzionalità di identity broker di Keycloak:

SAML 2.0 — Security Assertion Markup Language. Usato da IdP enterprise tra cui Microsoft Azure AD (Entra ID), Okta, ADFS, Ping Identity e Shibboleth. SAML usa assertion basate su XML firmate con certificati X.509.

OIDC (OpenID Connect) — Un moderno layer di identità su OAuth 2.0. Usato da Google Workspace, Okta (come provider OIDC), Microsoft Azure AD (supporta anche OIDC) e qualsiasi Authorization Server OAuth 2.0 con un endpoint di discovery OIDC.

Verifica del Dominio

Prima che una connessione SSO possa essere attivata, l’organizzazione deve dimostrare la proprietà del dominio email. Questo impedisce a un’organizzazione di intercettare i login per un dominio che non possiede.

La verifica usa un record DNS TXT:

1. Auris genera un token di verifica univoco per il dominio.
2. L’amministratore DNS dell’organizzazione crea un record TXT: _auris-verify.dominio.com con il token come valore.
3. Un admin clicca “Verifica” nella Console (o chiama l’API di verifica).
4. Auris esegue una ricerca DNS per il record TXT e conferma che il token corrisponde.

{
  "domain": "acme.com"
}

Risposta:

{
  "id": "dom_01HX...",
  "domain": "acme.com",
  "verificationToken": "auris-verify=a1b2c3d4e5f6...",
  "verificationMethod": "TXT",
  "status": "PENDING"
}

Record DNS da creare:

_auris-verify.acme.com  TXT  "auris-verify=a1b2c3d4e5f6..."

Configurazione SAML 2.0

{
  "type": "SAML",
  "name": "Acme Azure AD",
  "config": {
    "entityId": "https://sts.windows.net/tenant-id-here/",
    "ssoUrl": "https://login.microsoftonline.com/tenant-id/saml2",
    "certificate": "MIICIjANBgkq...",
    "signRequests": true,
    "nameIdFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
  }
}

{
  "attributeMapping": {
    "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
    "firstName": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
    "lastName": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
  }
}

Configurazione OIDC

{
  "type": "OIDC",
  "name": "Acme Google Workspace",
  "config": {
    "discoveryUrl": "https://accounts.google.com/.well-known/openid-configuration",
    "clientId": "123456789-abc.apps.googleusercontent.com",
    "clientSecret": "GOCSPX-...",
    "scopes": ["openid", "profile", "email"],
    "pkce": true
  }
}

https://auth.tuaapp.com/oidc/org-slug/callback

Flusso di Login SSO

Una volta che una connessione SSO è attiva e un dominio è verificato, il flusso di login cambia per gli utenti con indirizzi email corrispondenti:

1. L’utente inserisce la propria email nella pagina Hosted Login di Auris.
2. Auris chiama l’endpoint di rilevamento SSO:

{ "email": "[email protected]" }

Risposta quando l’SSO è configurato:

{
  "ssoRequired": true,
  "connectionType": "SAML",
  "organizationName": "Acme Corporation",
  "loginUrl": "/api/auth/sso/login/acme-azure-ad"
}

3. Auris reindirizza l’utente all’IdP tramite:

4. L’utente si autentica presso il proprio IdP aziendale.

5. L’IdP reindirizza ad Auris:

6. Auris emette il proprio access token e refresh token. Da questo momento, la sessione SSO è indipendente — le durate dei token Auris sono governate dalle impostazioni Auris, non dalla sessione dell’IdP.

Provisioning JIT (Just-in-Time)

Se un utente si autentica con successo all’IdP ma non ha un account Auris esistente, Auris ne crea uno automaticamente durante l’SSO callback. Questo è chiamato provisioning Just-in-Time.

Il provisioning JIT crea l’utente con:

• Email, firstName e lastName dalla risposta dell’IdP o dall’assertion SAML
• Membership nell’organizzazione legata alla connessione SSO
• Il ruolo default configurato per gli utenti provisioning JIT (configurabile per connessione, default: MEMBER)

L’account dell’utente persiste dopo il primo login — i login successivi si risolvono allo stesso account.

Connessioni SSO Multiple per Organizzazione

Un’organizzazione può avere più connessioni SSO attive — ad esempio, SAML per un deployment Azure AD e OIDC per un sottoinsieme di utenti su Google Workspace.

L’endpoint di rilevamento SSO abbina in base al dominio email verificato. Se più connessioni condividono lo stesso dominio, la connessione attivata più di recente ha la precedenza. In pratica, ogni connessione SSO dovrebbe essere associata a domini verificati distinti per evitare ambiguità.

Gestione delle Connessioni SSO

Procedura Guidata nella Console

La gestione SSO è disponibile sulla pagina di dettaglio dell’organizzazione nella Console Admin, nella scheda “Enterprise SSO”.

Aggiungere una connessione SAML:

1. Naviga su Console Admin → Organizzazioni → [Nome org] → Enterprise SSO.
2. Clicca “Aggiungi Connessione SSO”. Seleziona SAML 2.0.
3. Inserisci il metadata URL dell’IdP o incolla l’XML.
4. Revisiona la configurazione analizzata (Entity ID, SSO URL, certificato).
5. Salva. La connessione viene creata in stato inattivo.
6. Naviga nella scheda “Domini” e aggiungi il dominio email dell’organizzazione.
7. Aggiungi il record DNS TXT e clicca “Verifica Dominio”.
8. Una volta verificato il dominio, torna alla scheda SSO e clicca “Attiva”.

Aggiungere una connessione OIDC:

Stesso flusso, ma il form richiede Discovery URL, Client ID e Client Secret. Auris recupera automaticamente il documento di discovery e popola i campi rimanenti.

Permessi Richiesti

Pagine Correlate

• Organizzazioni B2B Multi-Tenant — Setup dell’organizzazione, ruoli dei membri e inviti
• SCIM 2.0 Provisioning — Provisioning automatico degli utenti per complementare l’SSO
• Hosted Login — Come la pagina Hosted Login si integra con il rilevamento SSO
• Console: Organizzazioni — Guida completa alla Console