Authentification tenant

SSO tenant et découverte d'identité

Les utilisateurs du dashboard tenant se connectent par une première étape calme: saisir une adresse e-mail. Attesto choisit ensuite le bon parcours mot de passe, identité communautaire, SSO d'organisation, invitation ou signup sans afficher un mur de boutons enterprise providers. Des community providers configurés peuvent aussi apparaître comme boutons de commodité sous le formulaire email-first, jamais au-dessus, et jamais mélangés aux choix enterprise SSO tenant.

Scope

Cette page couvre les main platform users sur dashboard.attesto.eu. Les marketplace developer accounts, auditor access et internal staff access sont des surfaces d'identité séparées. Un marketplace developer account ne donne pas accès au tenant dashboard, sauf si la même personne est aussi invitée comme tenant user.

Email discovery

La page de login commence par le champ e-mail. Le backend retourne la prochaine étape recommandée et, pour un nouveau community signup, peut aussi retourner des options sûres availableProviders:

Password fallback pour les password users existants.
Community identity quand un user existant est lié à Google, GitHub, GitLab ou LinkedIn.
Organization SSO lorsque le domaine e-mail correspond à un tenant provider activé.
Invite activation lorsqu'un invite token est présent.
Signup ou trial onboarding pour les adresses e-mail inconnues.

User flow

Les utilisateurs Enterprise SSO peuvent aussi commencer sur auth.attesto.eu. Cette page découvre uniquement les routes tenant Entra/OIDC/SAML et renvoie les utilisateurs sans SSO vers la connexion dashboard standard.

Un tenant user ne choisit pas entre sept providers. Il saisit son e-mail professionnel, vérifie la route découverte et continue avec la méthode configurée pour cette adresse. Si le domaine tenant est géré par organization SSO, le bouton indique “Continue with your organization” ou le nom du provider configuré. Si password fallback reste autorisé, les password users existants peuvent continuer avec password.

Ouvrez dashboard.attesto.eu/login.
Saisissez l'adresse e-mail tenant.
Continuez avec le parcours découvert: password, community identity, invite, signup ou organization SSO.
Revenez au dashboard avec la tenant session Attesto existante, la protection CSRF et les role checks intacts.

Tenant owner setup

Les tenant owners configurent les enterprise identity providers dans Settings → Identity Providers. L'assistant stocke les secrets côté serveur, ne renvoie au navigateur qu'un statut masqué et génère les valeurs callback ou metadata pour le provider externe. Le provider setup doit être testé avec un user invité avant d'imposer SSO pour un domaine tenant.

Provider	Quand l'utiliser	Attesto demande	Le provider demande
Microsoft Entra ID	Enterprise workforce login	Domain, issuer, client id, encrypted client secret	Redirect URI et users/groups autorisés
Generic OIDC	Okta, Keycloak, Ping, Auth0, ForgeRock ou custom OIDC	Domain, issuer URL, client id, encrypted client secret, scopes	Redirect URI et verified email claim
Generic SAML	Legacy enterprise SSO ou SAML-only IdPs	Domain, IdP entity id, SSO URL, signing certificate	SP Entity ID, ACS URL, signed response ou assertion

Providers

Les community providers prennent en charge Google, GitHub, GitLab et LinkedIn. Les enterprise providers prennent en charge Microsoft Entra ID, OIDC générique et SAML générique. Les choix enterprise provider ne sont pas affichés comme un mur de boutons public; discovery recommande le parcours tenant correspondant. Les community providers configurés peuvent apparaître sous le formulaire e-mail comme raccourci self-service. Le catalogue contient un flag configured, donc les providers non configurés restent visibles mais inertes tant que les vraies credentials OAuth n'existent pas.

Les community providers sont utiles aux évaluateurs, développeurs, investisseurs et consultants. Les enterprise providers sont tenant scoped: la correspondance de domaine détermine si un user doit être routé vers organization SSO. Les marketplace developer accounts restent séparés des tenant dashboard identities.

Microsoft Entra ID

Utilisez Microsoft Entra ID lorsqu'un client veut que l'accès au dashboard Attesto suive son Microsoft workforce identity, Conditional Access, MFA et ses account lifecycle policies. Dans Entra, créez une web application registration pour Attesto, ajoutez la redirect URI Attesto fournie par l'assistant du dashboard et créez un client secret. Dans Attesto, choisissez Entra, puis renseignez le tenant domain, l'issuer/authority URL, le client id et le client secret.

Le redirect type est web/confidential, pas public SPA.
Les scopes doivent inclure des OpenID Connect identity claims comme openid, email et profile.
Attesto exige un verified email et vérifie issuer, audience, nonce, state et PKCE.
Utilisez les politiques Conditional Access et MFA côté Entra pour l'assurance enterprise.

Generic OIDC

Generic OIDC couvre Okta, Keycloak, Ping, Auth0, ForgeRock et autres identity providers conformes aux standards. Le provider doit exposer un issuer avec discovery metadata et signing keys, et retourner un subject stable plus un verified email claim. Attesto découvre les endpoints authorization, token, userinfo et JWKS depuis l'issuer quand c'est supporté.

Créez une confidential/web OIDC app dans l'identity provider.
Collez la dashboard-generated callback URL dans le provider.
Configurez les allowed scopes, généralement openid email profile.
Enregistrez issuer URL, client id et client secret dans les Attesto tenant settings.
Effectuez un vrai login avec un user invité avant d'activer une strict tenant policy.

Generic SAML

Generic SAML prend en charge les environnements enterprise qui utilisent SAML 2.0 plutôt qu'OIDC. Attesto expose les SP metadata et ACS URLs depuis l'assistant tenant settings. L'IdP externe doit signer la response ou l'assertion et envoyer un subject stable plus un email attribute pour le tenant user invité.

Copiez les Attesto SP metadata ou saisissez manuellement Entity ID et ACS URL dans l'IdP.
Copiez IdP Entity ID, SSO URL et signing certificate dans Attesto.
Gardez les assertions courtes et incluez audience, recipient et InResponseTo values.
Reject unsigned, expired, replayed, wrong-audience ou wrong-recipient assertions.

Enterprise SSO

Enterprise SSO est tenant scoped. Une configuration provider lie un domaine tenant à un provider Entra, OIDC ou SAML activé. Pendant discovery, l'invite token et les identity links existants sont évalués d'abord, puis les tenant domain provider rules, puis le fallback password ou signup. Cela évite le choix arbitraire de provider et garde l'écran de login simple.

Les tenant owners configurent enterprise SSO dans les paramètres du dashboard sous Identity Providers. Les providers OIDC et Entra utilisent issuer metadata, client id, client secret chiffré, redirect allowlists strictes, PKCE, state, nonce, issuer, audience et verified-email checks. Les providers SAML utilisent signed responses ou assertions, audience et recipient validation, InResponseTo replay protection et une clock skew courte.

Le dashboard affiche les valeurs callback générées afin que les tenant owners puissent les copier dans l'identity provider externe:

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}

Les docs publiques ne documentent volontairement pas les internal staff admin procedures. Cette page vise la tenant-owned identity configuration et la developer integration avec les tenant authentication endpoints.

Invites

Invite acceptance utilise le même discovery model. Si l'e-mail de l'invitation appartient à un domaine tenant avec required organization SSO, l'invitation peut continuer via ce provider. Si aucun provider n'est requis, le user peut encore définir un password via le parcours d'invitation existant.

API contract

Ces endpoints sont des dashboard tenant-auth endpoints. Les frontend clients ne reçoivent jamais de 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": "/"
}

Une discovery response indique au frontend quelle unique prochaine étape afficher. Provider secrets, client secrets, SAML certificates, tokens et assertions ne sont jamais renvoyés au navigateur.

{
  "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 retourne seulement des labels community provider non secrets et l'état de configuration pour les boutons sous le formulaire e-mail. POST /v1/auth/external/start peut être appelé avec seulement providerId pour le global community signup, mais les tenant enterprise providers exigent toujours un discovery result email-backed ou invite-backed.

Security

External login n'est autorisé que lorsque le provider retourne un verified email et que l'identity peut être liée à un tenant user existant, une invite acceptée ou une signup/trial creation explicite. Provider secrets, SAML private settings, tokens, assertions et raw callbacks restent server-side. Les audit events enregistrent discovery, provider start, success, failure, provider changes et identity linking sans journaliser de raw secrets.

Control	Ce qu'Attesto impose
OAuth/OIDC state	Les short-lived state, nonce et PKCE records sont single-use.
OIDC token validation	Issuer, audience, JWKS signature, nonce et verified email sont vérifiés.
SAML replay protection	InResponseTo, audience, recipient, signature et clock skew sont validés.
Identity linking	Seuls les verified emails peuvent être liés à des users existants, accepted invites ou explicit signup/trial creation.
Secret handling	Les provider secrets sont chiffrés server-side et masqués dans les tenant settings.
Surface separation	Tenant dashboard users, marketplace developer accounts, auditors et internal staff auth restent des surfaces séparées.

Troubleshooting

Symptôme	Cause probable	Correction
User routé vers password au lieu de SSO	Domain provider disabled, domain mismatch ou existing password identity prioritaire.	Vérifiez tenant domain, provider enabled state et orthographe de l'invite email.
OIDC callback échoue	Redirect URI, issuer, audience, nonce ou verified email claim ne correspond pas.	Copiez exactement le generated callback et vérifiez issuer/client configuration.
SAML assertion rejetée	Unsigned, expired, replayed, wrong audience, wrong recipient ou email attribute manquant.	Activez signed responses/assertions et comparez Entity ID, ACS URL et attributes.
Bouton community provider désactivé	Le provider est listé dans le catalogue mais `configured` vaut false.	Ajoutez le vrai OAuth client id/secret avant d'activer ce parcours pour les users.
User authentifié mais bloqué hors tenant	L'external identity n'est pas liée à un tenant user invité ou existant.	Invitez d'abord le user ou utilisez l'explicit signup/trial path pour un nouveau tenant.

Rollout checklist

Configurez le provider domain et les issuer values dans tenant settings.
Copiez l'URL callback, ACS ou metadata générée dans le provider externe.
Invitez un tenant user avec ce domaine et effectuez un vrai login.
Confirmez que le provider externe retourne le verified email claim ou SAML email attribute attendu.
Vérifiez que password fallback fonctionne encore pour les users qui en ont besoin.
Documentez tenant-side MFA et access policy ownership avec le client.
Contrôlez les audit events et tenant session behavior avant d'imposer une SSO policy.