Autenticazione tenant

SSO tenant e scoperta dell'identità

Gli utenti del dashboard tenant accedono con un primo passo semplice: inserire un indirizzo e-mail. Attesto sceglie poi il percorso corretto tra password, community identity, organization SSO, invite o signup senza mostrare un muro di enterprise provider. I community providers configurati possono anche apparire come pulsanti di convenienza sotto il modulo email-first, mai sopra, e mai mescolati con le scelte tenant enterprise SSO.

Scope

Questa pagina copre i main platform users su dashboard.attesto.eu. Marketplace developer accounts, auditor access e internal staff access sono superfici di identità separate. Un marketplace developer account non consente l'accesso al tenant dashboard, salvo che la stessa persona sia anche invitata come tenant user.

Email discovery

La pagina di login parte dal campo e-mail. Il backend restituisce il prossimo passo consigliato e, per un nuovo community signup, può anche restituire opzioni sicure availableProviders:

Password fallback per password users esistenti.
Community identity quando un user esistente è collegato a Google, GitHub, GitLab o LinkedIn.
Organization SSO quando il dominio e-mail corrisponde a un tenant provider abilitato.
Invite activation quando è presente un invite token.
Signup o trial onboarding per indirizzi e-mail sconosciuti.

User flow

Gli utenti Enterprise SSO possono iniziare anche da auth.attesto.eu. Questa pagina rileva solo route tenant Entra/OIDC/SAML e rimanda gli utenti senza SSO al login dashboard normale.

Un tenant user non sceglie tra sette provider. Inserisce la propria e-mail di lavoro, verifica la route scoperta e continua con il metodo configurato per quell'indirizzo. Se il dominio tenant è controllato da organization SSO, il pulsante dice “Continue with your organization” o il nome provider configurato. Se password fallback è ancora consentito, i password users esistenti possono continuare con password.

Apri dashboard.attesto.eu/login.
Inserisci l'indirizzo e-mail tenant.
Continua con il percorso scoperto: password, community identity, invite, signup o organization SSO.
Ritorna al dashboard con tenant session Attesto esistente, protezione CSRF e role checks intatti.

Tenant owner setup

I tenant owners configurano enterprise identity providers in Settings → Identity Providers. Il wizard conserva i secrets server-side, mostra al browser solo status mascherato e genera valori callback o metadata per il provider esterno. Il provider setup deve essere testato con un user invitato prima di imporre SSO per un dominio tenant.

Provider	Quando usarlo	Attesto richiede	Il provider richiede
Microsoft Entra ID	Enterprise workforce login	Domain, issuer, client id, encrypted client secret	Redirect URI e users/groups consentiti
Generic OIDC	Okta, Keycloak, Ping, Auth0, ForgeRock o custom OIDC	Domain, issuer URL, client id, encrypted client secret, scopes	Redirect URI e verified email claim
Generic SAML	Legacy enterprise SSO o SAML-only IdPs	Domain, IdP entity id, SSO URL, signing certificate	SP Entity ID, ACS URL, signed response o assertion

Providers

I community providers supportano Google, GitHub, GitLab e LinkedIn. Gli enterprise providers supportano Microsoft Entra ID, OIDC generico e SAML generico. Le scelte enterprise provider non vengono mostrate come un muro pubblico di pulsanti; discovery raccomanda il percorso tenant corrispondente. I community providers configurati possono apparire sotto il modulo e-mail come shortcut self-service. Il catalogo contiene un flag configured, quindi i provider non configurati sono visibili ma inerti finché non esistono vere OAuth credentials.

I community providers sono utili per valutatori, developers, investitori e consulenti. Gli enterprise providers sono tenant scoped: la corrispondenza del dominio determina se un user deve essere indirizzato verso organization SSO. Marketplace developer accounts restano separati da tenant dashboard identities.

Microsoft Entra ID

Usa Microsoft Entra ID quando un cliente vuole che l'accesso al dashboard Attesto segua Microsoft workforce identity, Conditional Access, MFA e account lifecycle policies. In Entra crea una web application registration per Attesto, aggiungi la Attesto redirect URI dal wizard del dashboard e crea un client secret. In Attesto scegli Entra, inserisci tenant domain, issuer/authority URL, client id e client secret.

Il redirect type è web/confidential, non public SPA.
Gli scopes devono includere OpenID Connect identity claims come openid, email e profile.
Attesto richiede verified email e controlla issuer, audience, nonce, state e PKCE.
Usa Conditional Access e MFA policies lato Entra per enterprise assurance.

Generic OIDC

Generic OIDC copre Okta, Keycloak, Ping, Auth0, ForgeRock e altri identity providers conformi agli standard. Il provider deve esporre issuer discovery metadata e signing keys, e restituire un subject stabile più verified email claim. Attesto scopre gli endpoint authorization, token, userinfo e JWKS dall'issuer dove supportato.

Crea una confidential/web OIDC app nell'identity provider.
Incolla la dashboard-generated callback URL nel provider.
Configura allowed scopes, di solito openid email profile.
Salva issuer URL, client id e client secret in Attesto tenant settings.
Esegui un login reale con un user invitato prima di abilitare strict tenant policy.

Generic SAML

Generic SAML supporta ambienti enterprise che usano SAML 2.0 invece di OIDC. Attesto espone SP metadata e ACS URLs dal wizard tenant settings. L'IdP esterno deve firmare response o assertion e inviare un subject stabile più email attribute per il tenant user invitato.

Copia Attesto SP metadata o inserisci manualmente Entity ID e ACS URL nell'IdP.
Copia IdP Entity ID, SSO URL e signing certificate in Attesto.
Mantieni le assertions a breve durata e includi audience, recipient e InResponseTo values.
Reject unsigned, expired, replayed, wrong-audience o wrong-recipient assertions.

Enterprise SSO

Enterprise SSO è tenant scoped. Una configurazione provider lega un dominio tenant a un provider Entra, OIDC o SAML abilitato. Durante discovery, invite token e identity links esistenti vengono valutati per primi, poi tenant domain provider rules, poi password o signup fallback. Questo evita una scelta casuale del provider e mantiene semplice la schermata di login.

I tenant owners configurano enterprise SSO nelle dashboard settings sotto Identity Providers. I provider OIDC ed Entra usano issuer metadata, client id, client secret cifrato, strict redirect allowlists, PKCE, state, nonce, issuer, audience e verified-email checks. I provider SAML usano signed responses o assertions, validazione di audience e recipient, InResponseTo replay protection e clock skew breve.

Il dashboard mostra valori callback generati così i tenant owners possono copiarli nell'identity provider esterno:

OAuth/OIDC callback:
https://auth.attesto.eu/v1/auth/external/callback/{provider_id}

SAML ACS:
https://auth.attesto.eu/v1/auth/saml/acs/{provider_id}

SAML metadata:
https://auth.attesto.eu/v1/auth/saml/metadata/{provider_id}

Le docs pubbliche non documentano intenzionalmente internal staff admin procedures. Questa pagina è per tenant-owned identity configuration e developer integration con i tenant authentication endpoints.

Invites

Invite acceptance usa lo stesso discovery model. Se l'e-mail dell'invite appartiene a un dominio tenant con required organization SSO, l'invite può continuare tramite quel provider. Se non è richiesto alcun provider, il user può ancora impostare una password attraverso il percorso invite esistente.

API contract

Questi endpoint sono dashboard tenant-auth endpoints. I frontend clients non ricevono mai provider secrets.

POST /v1/auth/discover
GET /v1/auth/providers
POST /v1/auth/external/start
GET /v1/auth/external/callback/{provider_id}
POST /v1/auth/saml/acs/{provider_id}
GET /v1/auth/saml/metadata/{provider_id}

{
  "email": "user@company.com",
  "returnTo": "/"
}

Una discovery response dice al frontend quale singolo prossimo passo renderizzare. Provider secrets, client secrets, SAML certificates, tokens e assertions non vengono mai restituiti al browser.

{
  "email": "user@company.com",
  "action": "organization_sso",
  "buttonLabel": "Continue with your organization",
  "providerId": "idp_...",
  "providerType": "oidc",
  "allowPassword": false,
  "allowSignup": false,
  "availableProviders": []
}

GET /v1/auth/providers restituisce solo labels non-secret dei community providers e stato di configurazione per i pulsanti sotto il modulo e-mail. POST /v1/auth/external/start può essere chiamato solo con providerId per global community signup, ma i tenant enterprise providers richiedono sempre un discovery result email-backed o invite-backed.

Security

External login è consentito solo quando il provider restituisce verified email e l'identity può essere collegata a un tenant user esistente, a un accepted invite o a una explicit signup/trial creation. Provider secrets, SAML private settings, tokens, assertions e raw callbacks restano server-side. Audit events registrano discovery, provider start, success, failure, provider changes e identity linking senza loggare raw secrets.

Control	Cosa impone Attesto
OAuth/OIDC state	Short-lived state, nonce e PKCE records sono single-use.
OIDC token validation	Issuer, audience, JWKS signature, nonce e verified email vengono controllati.
SAML replay protection	InResponseTo, audience, recipient, signature e clock skew vengono validati.
Identity linking	Solo verified emails possono collegarsi a users esistenti, accepted invites o explicit signup/trial creation.
Secret handling	Provider secrets sono cifrati server-side e mascherati in tenant settings.
Surface separation	Tenant dashboard users, marketplace developer accounts, auditors e internal staff auth restano surfaces separate.

Troubleshooting

Sintomo	Causa probabile	Correzione
User indirizzato a password invece che SSO	Domain provider disabled, domain mismatch o existing password identity con precedence.	Controlla tenant domain, provider enabled state e ortografia dell'invite email.
OIDC callback fails	Redirect URI, issuer, audience, nonce o verified email claim non corrisponde.	Copia esattamente il generated callback e verifica issuer/client configuration.
SAML assertion rejected	Unsigned, expired, replayed, wrong audience, wrong recipient o email attribute mancante.	Abilita signed responses/assertions e confronta Entity ID, ACS URL e attributes.
Community provider button disabilitato	Il provider è nel catalogo ma `configured` è false.	Aggiungi il vero OAuth client id/secret prima di abilitare quel percorso per gli users.
User autentica ma non entra nel tenant	L'external identity non è collegata a un tenant user invitato o esistente.	Invita prima il user o usa l'explicit signup/trial path per un nuovo tenant.

Rollout checklist

Configura provider domain e issuer values in tenant settings.
Copia callback, ACS o metadata URL generati nel provider esterno.
Invita un tenant user con quel dominio e completa un login reale.
Conferma che il provider esterno restituisca il verified email claim o SAML email attribute previsto.
Verifica che password fallback funzioni ancora per i users che ne hanno bisogno.
Documenta tenant-side MFA e access policy ownership con il cliente.
Controlla audit events e tenant session behavior prima di imporre SSO policy.