Login & Sicherheit mit Auth0 (Okta) in Claimspace

Auth0 (by Okta) ist der Login‑Provider von Claimspace. Damit meldest du dich sicher, schnell und flexibel an – ob mit einem Claimspace-Account oder über das firmeneigene Single Sign-On (SSO). Auth0 bringt moderne Sicherheitsmechanismen wie MFA, adaptive Risikoerkennung und standardisierte Protokolle (OIDC/SAML) mit. So bleiben Zugriffe geschützt und Benutzerverwaltung lässt sich zentral in deinem Unternehmen steuern.

Kurzfassung

• Zwei Wege: Claimspace-verwalteter Auth0-Account oder Anbindung eures eigenen Login-Providers (BYO IdP).
• Sicher: MFA, WebAuthn/Passkeys, adaptive Risikoerkennung, Bruteforce-/Bot-Schutz, kurze Token-Lebenszeiten.
• Standardisiert: OIDC/SAML, SCIM (optional) für Provisionierung, rollenbasierte Zugriffssteuerung (RBAC).
• DSGVO-orientiert: Datenminimierung, vertragliche Absicherung, Audit-Logs. Details auf Anfrage.

Wie die Anmeldung funktioniert

1. Du öffnest den Claimspace-Login und wählst entweder:
   • „E-Mail/Passwort“ (Claimspace-verwalteter Auth0-Zugang), oder
   • „Mit Firmen-SSO anmelden“ (euer IdP wie Microsoft Entra ID/Azure AD, Okta, Google Workspace, ADFS u. a.).
2. Auth0 übernimmt die Authentifizierung – je nach Option per Passwort, Passkey/WebAuthn, MFA oder direkt über euren IdP.
3. Nach erfolgreicher Prüfung erhält Claimspace ein kurzlebiges OIDC-Token (Authorization Code + PKCE).
4. Claimspace liest die freigegebenen Attribute (z. B. E-Mail, Name, Gruppen/Claims) ein und weist dir die passenden Rollen und Rechte zu.
5. Du landest direkt im jeweiligen Bereich – ohne zusätzliche Nachfragen.

Optionen für Unternehmen

A) Claimspace-verwalteter Auth0-Account (Out-of-the-box)

• Schnell startklar ohne eigene IdP-Integration.
• MFA-Policies, Passwortregeln, E-Mail-Verifizierung und gesicherte Passkey-Optionen werden zentral betrieben.
• Benutzerverwaltung über Claimspace-Administratoren (Einladen, Deaktivieren, Rollen zuweisen) oder auf Wunsch via SCIM/JIT.

B) Bring your own Identity (BYO IdP)

• Unterstützte Protokolle: SAML 2.0 und OpenID Connect (OIDC).
• Unterstützte IdPs (Auswahl): Microsoft Entra ID (Azure AD), Okta, Google Workspace, ADFS, weitere SAML/OIDC‑Provider. On-Prem via AD/LDAP-Connector möglich.
• Single Sign-On: SP‑initiierte und IdP‑initiierte Flows. Empfehlung: SP‑initiiert, um Routing und Benutzererlebnis zu vereinheitlichen.
• Attribute- und Gruppen‑Mapping: IdP‑Gruppen/Claims werden auf Claimspace‑Rollen abgebildet (z. B. Schadenbearbeitung, Freigaben, Reporting).
• Just‑in‑Time (JIT) Provisioning: Nutzer werden beim ersten Login automatisch angelegt.
• SCIM 2.0 (optional): Automatisierte Benutzer‑ und Gruppenpflege direkt aus eurem IdP (Create/Update/Deactivate).
• Fallback-Zugänge: Auf Wunsch „Break‑Glass“-Konten für Notfälle (getrennte MFA, starke Richtlinien).

C) Eigenes Auth0‑Tenant

• Wenn ihr bereits Auth0 nutzt, können wir zwischen eurem und unserem Auth0 via OIDC/SAML föderieren.
• Nutzt eure bestehenden Flows, Richtlinien und MFA, während Claimspace nur die benötigten Claims erhält.
• Ideal, wenn ihr konsistente Policies über mehrere Anwendungen hinweg beibehalten wollt.

Sicherheitsmaßnahmen von Auth0 (by Okta)

• Starke Authentifizierung
  • Multi‑Factor Authentication (MFA): TOTP‑Apps, Push/Okta Verify, WebAuthn/Passkeys; SMS/Voice optional.
  • Passwordless/Passkeys: Anmelden per Gerätesicherheit (z. B. Face/Touch ID, Sicherheitsschlüssel).
  • Adaptive MFA: Risikoabhängige Prüfung (z. B. neues Gerät, ungewöhnlicher Standort).
• Schutzmechanismen
  • Bruteforce- und Bot‑Erkennung, Rate Limiting, Anomalieerkennung.
  • E‑Mail‑Verifizierung, Erkennung kompromittierter Passwörter.
• Sichere Token & Sessions
  • OIDC/OAuth 2.0 mit Authorization Code + PKCE, kurzlebige Access Tokens, Refresh‑Token‑Rotation und Widerruf.
  • Fein granulierte Scopes/Claims, um nur notwendige Berechtigungen zu erteilen.
• Verschlüsselung & Transport
  • TLS für Daten in Transit; serverseitige Verschlüsselung für Daten at Rest bei Auth0.
• Audit & Monitoring
  • Detaillierte Authentifizierungs‑ und Admin‑Logs, Ausgabe an SIEM/Monitoring möglich.
• Compliance
  • Auth0/Okta arbeitet nach anerkannten Sicherheits‑ und Compliance‑Standards (z. B. ISO/SOC). Konkrete Zertifikate und Berichte stellen wir dir auf Anfrage bereit.

Benutzer- und Rechteverwaltung

• Zentral im Unternehmen (empfohlen bei BYO IdP)
  • Zugriffsrechte werden über eure Gruppen/Rollen verwaltet; Änderungen wirken nach Re‑Login sofort.
  • Deprovisioning im IdP entzieht den Zugriff auch in Claimspace (JIT/SCIM).
• Über Claimspace (bei Claimspace‑verwaltetem Auth0)
  • Admins laden Nutzer ein, vergeben Rollen, setzen Passwort‑Resets durch und erzwingen MFA‑Richtlinien.
  • Rollenmodell: Wir bilden Funktionen wie Sachbearbeitung, Gutachter, Prüfer, Admin u. a. ab. Mapping auf IdP‑Gruppen ist möglich.

Datenschutz & DSGVO

• Datenminimierung: Fürs Login benötigen wir nur wenige Identitätsdaten (z. B. E‑Mail, Name, optionale Gruppen/Claims).
• Zweckbindung: Nutzerdaten werden ausschließlich zur Authentifizierung, Autorisierung und Nachvollziehbarkeit (Audit) verwendet.
• Auftragsverarbeitung: Claimspace ist Auftragsverarbeiter, Auth0/Okta ein Unterauftragsverarbeiter. Relevante Vereinbarungen (inkl. TOMs) stellen wir auf Anfrage bereit.
• Datenresidenz: Auth0 bietet Regions‑Optionen. Wir konfigurieren deine Umgebung entsprechend deinen Compliance‑Vorgaben, soweit verfügbar.
• Auskunft & Löschung: Auf Anfrage unterstützen wir bei Auskunft, Berichtigung, Sperrung/Löschung entsprechend rechtlicher Vorgaben.

Einrichtung: Was wir von dir benötigen (BYO IdP)

• Protokoll: OIDC oder SAML (Empfehlung: OIDC).
• Metadaten
  • OIDC: Issuer/Discovery‑URL, Client ID/Secret (falls Confidential), unterstützte Claims/Scopes.
  • SAML: Metadata XML/URL, Entity ID, ACS/Recipient, Zertifikat, NameID‑Format.
• Attribute/Claims: E‑Mail (verifiziert), Name; optional Gruppen/Rollen für RBAC‑Mapping.
• SCIM (optional): SCIM‑Base‑URL, Bearer Token, gewünschtes Attribut‑Mapping.
• Domains: E‑Mail‑Domänen für automatisches IdP‑Routing.
• Testzugänge: Mindestens zwei Testuser (Standardrolle und Admin), ggf. MFA‑Vorgaben.
• Fallback: Benennung eines „Break‑Glass“-Admins und Abstimmung des Notfallprozesses.
• Go‑Live‑Fenster: Termin für Tests, Pilot und Rollout.

‍