Tenant-Authentifizierung

Tenant SSO und Identity Discovery

Dashboard-Tenant-User melden sich mit einem ruhigen ersten Schritt an: E-Mail-Adresse eingeben. Attesto wählt danach den passenden Passwort-, Community-Identity-, Organisations-SSO-, Invite- oder Signup-Pfad, ohne eine Enterprise Provider Wall zu zeigen. Konfigurierte Community Provider können zusätzlich als Convenience Buttons unter dem email-first Formular erscheinen, niemals darüber, und niemals gemischt mit Tenant Enterprise SSO-Auswahl.

Scope

Diese Seite behandelt main platform users auf dashboard.attesto.eu. Marketplace developer accounts, auditor access und interner staff access sind getrennte Identity-Oberflächen. Ein Marketplace developer account öffnet das tenant dashboard nicht, außer dieselbe Person ist auch als tenant user eingeladen.

Email discovery

Die Login-Seite startet mit dem E-Mail-Feld. Das Backend gibt den empfohlenen nächsten Schritt zurück und kann für einen neuen Community Signup auch sichere availableProviders-Optionen zurückgeben:

Password fallback für bestehende password users.
Community identity, wenn ein bestehender user mit Google, GitHub, GitLab oder LinkedIn verknüpft ist.
Organization SSO, wenn die E-Mail-Domain zu einem aktivierten tenant provider passt.
Invite activation, wenn ein invite token vorhanden ist.
Signup oder trial onboarding für unbekannte E-Mail-Adressen.

User flow

Enterprise-SSO-Nutzer können auch auf auth.attesto.eu starten. Diese Seite erkennt nur Tenant Entra/OIDC/SAML-Routen und sendet Nutzer ohne SSO zurück zum regulären Dashboard-Login.

Ein tenant user muss nicht zwischen sieben Providern wählen. Der User gibt seine Arbeits-E-Mail ein, prüft die erkannte Route und fährt mit der für diese Adresse konfigurierten Methode fort. Wenn die Tenant-Domain durch organization SSO kontrolliert wird, lautet der Button “Continue with your organization” oder zeigt den konfigurierten Providernamen. Wenn password fallback noch erlaubt ist, können bestehende password users mit password fortfahren.

Öffnen Sie dashboard.attesto.eu/login.
Geben Sie die Tenant-E-Mail-Adresse ein.
Fahren Sie mit dem erkannten password-, community identity-, invite-, signup- oder organization SSO-Pfad fort.
Kehren Sie zum Dashboard zurück; bestehende Attesto tenant session, CSRF-Schutz und role checks bleiben intakt.

Tenant owner setup

Tenant owners konfigurieren enterprise identity providers unter Settings → Identity Providers. Der Wizard speichert Secrets serverseitig, zeigt dem Browser nur maskierten Status und generiert Callback- oder Metadatenwerte für den externen Provider. Provider setup sollte mit einem eingeladenen User getestet werden, bevor SSO für eine Tenant-Domain erzwungen wird.

Provider	Einsatzfall	Attesto benötigt	Provider benötigt
Microsoft Entra ID	Enterprise workforce login	Domain, issuer, client id, encrypted client secret	Redirect URI und erlaubte users/groups
Generic OIDC	Okta, Keycloak, Ping, Auth0, ForgeRock oder custom OIDC	Domain, issuer URL, client id, encrypted client secret, scopes	Redirect URI und verified email claim
Generic SAML	Legacy enterprise SSO oder SAML-only IdPs	Domain, IdP entity id, SSO URL, signing certificate	SP Entity ID, ACS URL, signed response oder assertion

Providers

Community providers unterstützen Google, GitHub, GitLab und LinkedIn. Enterprise providers unterstützen Microsoft Entra ID, generisches OIDC und generisches SAML. Enterprise Provider-Auswahl wird nicht als öffentliche Button-Wand angezeigt; discovery empfiehlt den passenden Tenant-Pfad. Konfigurierte Community Provider können unter dem E-Mail-Formular als Self-service Shortcut erscheinen. Der Katalog enthält eine configured-Flag, sodass nicht konfigurierte Provider sichtbar, aber inert sind, bis echte OAuth Credentials vorhanden sind.

Community providers eignen sich für Evaluatoren, Developers, Investoren und Consultants. Enterprise providers sind tenant scoped: der Domain-Match entscheidet, ob ein User zu organization SSO geleitet wird. Marketplace developer accounts bleiben von tenant dashboard identities getrennt.

Microsoft Entra ID

Verwenden Sie Microsoft Entra ID, wenn ein Kunde Attesto dashboard access an Microsoft workforce identity, Conditional Access, MFA und account lifecycle policies koppeln möchte. Erstellen Sie in Entra eine web application registration für Attesto, fügen Sie die Attesto redirect URI aus dem Dashboard-Wizard hinzu und erstellen Sie ein client secret. Wählen Sie in Attesto Entra und tragen Sie tenant domain, issuer/authority URL, client id und client secret ein.

Der redirect type ist web/confidential, nicht public SPA.
Scopes sollten OpenID Connect identity claims wie openid, email und profile enthalten.
Attesto verlangt eine verified email und prüft issuer, audience, nonce, state und PKCE.
Nutzen Sie Entra Conditional Access und MFA policies für enterprise assurance.

Generic OIDC

Generic OIDC deckt Okta, Keycloak, Ping, Auth0, ForgeRock und andere standards-compliant identity providers ab. Der Provider muss issuer discovery metadata und signing keys bereitstellen und einen stabilen subject plus verified email claim zurückgeben. Attesto entdeckt authorization-, token-, userinfo- und JWKS-endpoints aus dem issuer, wo dies unterstützt wird.

Erstellen Sie eine confidential/web OIDC app im identity provider.
Fügen Sie die dashboard-generated callback URL im Provider ein.
Konfigurieren Sie allowed scopes, normalerweise openid email profile.
Speichern Sie issuer URL, client id und client secret in Attesto tenant settings.
Führen Sie einen echten Login mit einem eingeladenen User aus, bevor strict tenant policy aktiviert wird.

Generic SAML

Generic SAML unterstützt Enterprise-Umgebungen, die SAML 2.0 statt OIDC verwenden. Attesto zeigt SP metadata und ACS URLs im Tenant Settings Wizard. Der externe IdP muss response oder assertion signieren und einen stabilen subject plus email attribute für den eingeladenen tenant user senden.

Kopieren Sie Attesto SP metadata oder geben Sie Entity ID und ACS URL manuell im IdP ein.
Kopieren Sie IdP Entity ID, SSO URL und signing certificate zurück nach Attesto.
Halten Sie assertions kurzlebig und enthalten Sie audience, recipient und InResponseTo values.
Reject unsigned, expired, replayed, wrong-audience oder wrong-recipient assertions.

Enterprise SSO

Enterprise SSO ist tenant scoped. Eine Provider-Konfiguration bindet eine Tenant-Domain an genau einen aktivierten Entra-, OIDC- oder SAML-Provider. Während discovery werden invite token und bestehende identity links zuerst ausgewertet, danach tenant domain provider rules, danach password oder signup fallback. Dadurch gibt es keine zufällige Provider-Auswahl und die Login-Seite bleibt einfach.

Tenant Owners konfigurieren Enterprise SSO in den Dashboard Settings unter Identity Providers. OIDC- und Entra-Provider nutzen Issuer Metadata, Client ID, verschlüsseltes Client Secret, strikte Redirect Allowlists, PKCE, State, Nonce, Issuer, Audience und verified-email checks. SAML-Provider nutzen signed responses oder assertions, Audience- und Recipient-Validierung, InResponseTo replay protection und kurze clock skew.

Das Dashboard zeigt generierte Callback-Werte, damit Tenant Owners sie in den externen Identity Provider kopieren können:

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}

Öffentliche Docs dokumentieren bewusst keine internen staff admin procedures. Diese Seite ist für tenant-owned identity configuration und developer integration mit den tenant authentication endpoints.

Invites

Invite acceptance nutzt dasselbe discovery model. Wenn die Invite E-Mail zu einer Tenant-Domain mit required organization SSO gehört, kann die Invite über diesen Provider fortgesetzt werden. Wenn kein Provider erforderlich ist, kann der User weiterhin über den bestehenden Invite-Pfad ein password setzen.

API contract

Diese Endpoints sind dashboard tenant-auth endpoints. Frontend clients erhalten niemals 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": "/"
}

Eine discovery response sagt dem Frontend, welchen einzelnen nächsten Schritt es rendern soll. Provider secrets, client secrets, SAML certificates, tokens und assertions werden niemals an den Browser zurückgegeben.

{
  "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 gibt nur non-secret Community Provider Labels und Konfigurationsstatus für die Buttons unter dem E-Mail-Formular zurück. POST /v1/auth/external/start darf für global community signup nur mit providerId aufgerufen werden, aber Tenant Enterprise Provider benötigen immer ein email- oder invite-backed Discovery Result.

Security

External login ist nur erlaubt, wenn der Provider eine verified email zurückgibt und die identity mit einem bestehenden tenant user, einer akzeptierten invite oder expliziter signup/trial creation verknüpft werden kann. Provider secrets, SAML private settings, tokens, assertions und raw callbacks bleiben server-side. Audit events erfassen discovery, provider start, success, failure, provider changes und identity linking, ohne raw secrets zu loggen.

Control	Was Attesto erzwingt
OAuth/OIDC state	Short-lived state, nonce und PKCE records sind single-use.
OIDC token validation	Issuer, audience, JWKS signature, nonce und verified email werden geprüft.
SAML replay protection	InResponseTo, audience, recipient, signature und clock skew werden validiert.
Identity linking	Nur verified emails dürfen mit bestehenden users, accepted invites oder explicit signup/trial creation verknüpft werden.
Secret handling	Provider secrets werden serverseitig verschlüsselt und in tenant settings maskiert.
Surface separation	Tenant dashboard users, marketplace developer accounts, auditors und internal staff auth bleiben getrennte surfaces.

Troubleshooting

Symptom	Wahrscheinliche Ursache	Fix
User wird zu password statt SSO geleitet	Domain provider ist disabled, domain mismatch oder bestehende password identity hat precedence.	Prüfen Sie tenant domain, provider enabled state und Schreibweise der invite email.
OIDC callback schlägt fehl	Redirect URI, issuer, audience, nonce oder verified email claim passt nicht.	Kopieren Sie den generated callback exakt und prüfen Sie issuer/client configuration.
SAML assertion wird abgelehnt	Unsigned, expired, replayed, wrong audience, wrong recipient oder fehlendes email attribute.	Aktivieren Sie signed responses/assertions und vergleichen Sie Entity ID, ACS URL und attributes.
Community Provider Button ist disabled	Der Provider steht im Katalog, aber `configured` ist false.	Fügen Sie die echten OAuth client id/secret hinzu, bevor Sie diesen Pfad für Users aktivieren.
User authentifiziert, kommt aber nicht in den tenant	Die external identity ist nicht mit einem eingeladenen oder bestehenden tenant user verknüpft.	Laden Sie den User zuerst ein oder nutzen Sie den explicit signup/trial path für einen neuen Tenant.

Rollout checklist

Konfigurieren Sie provider domain und issuer values in tenant settings.
Kopieren Sie die generierte callback-, ACS- oder metadata-URL in den externen Provider.
Laden Sie einen tenant user mit dieser Domain ein und führen Sie einen echten Login durch.
Bestätigen Sie, dass der externe Provider den erwarteten verified email claim oder das SAML email attribute zurückgibt.
Prüfen Sie, dass password fallback für Users funktioniert, die ihn benötigen.
Dokumentieren Sie tenant-side MFA und access policy ownership mit dem Kunden.
Prüfen Sie audit events und tenant session behavior, bevor SSO policy erzwungen wird.