Zum Inhalt springen
← Alle Szenarien

B2B SaaS / Kunden-Onboarding

Machen Sie Kundenidentität zum Teil Ihres SaaS-Onboardings.

Kontrollieren Sie die Identity-Plattform hinter Ihrem SaaS. Bieten Sie jedem Unternehmen lokale Konten oder seine bestehende Unternehmensidentität mit einer Mandantenkonfiguration passend zu Ihrem Onboarding.

Ihr Onboarding planen
Ihr SaaS-ProduktEine gemeinsame Integration.OpenID Connect / OAuth 2.0
ProAuthDie gemeinsame Identity-Plattform
Kunde A / MandantLokale Konten

ProAuth-Benutzerverzeichnis

Kunde B / MandantUnternehmensidentität

Externer OpenID Provider

Kunde C / MandantBeide Möglichkeiten

Lokale Konten + Föderation

Illustrative Mandantenkonfigurationen innerhalb einer ProAuth-Plattform.

Die Ausgangslage

Kundenanforderungen ändern sich. Die Integration bleibt vertraut.

Eine B2B-Anwendung bedient kleinere Unternehmen mit lokalen Konten und grössere mit eigenen Identity Providern. Ein neuer Kunde möchte sein Verzeichnis beim Onboarding anbinden.

Illustratives Geschäftsbeispiel, kein Kundenbericht.

Kundenentscheidungen in Mandantenkonfiguration übersetzen

Management API / Laufzeitkonfiguration

  1. 01

    Anforderungen erfassen. Konfiguration anwenden.

    Ihr Onboarding-Portal kann Anforderungen erfassen und über die Management API einen Mandanten, seine Identitätsquellen und unterstützte Einstellungen zur Laufzeit konfigurieren. Diese zusätzliche Konfiguration erfordert kein erneutes Deployment von ProAuth.

  2. 02

    Identitätsquellen mit dem Kunden einrichten.

    Für lokale Konten konfigurieren Sie ein ProAuth-Benutzerverzeichnis. Für die Unternehmensanmeldung richtet der Kundenadministrator die OIDC-Anbindung in den gewählten Identity Providern ein und liefert die benötigte Konfiguration. Wenn Verzeichnis-Provisionierung erforderlich ist, konfigurieren Sie zusätzlich die separate SCIM-Verbindung.

  3. 03

    Den Ablauf in Ihren Werkzeugen gestalten.

    Dieses Muster wird in kundeneigenen Onboarding-Werkzeugen genutzt: Der Assistent sammelt Einstellungen, wendet Konfiguration an und prüft die Integration. Ausnahmen gehen an den Support. ProAuth stellt die APIs bereit; Ihr Team gestaltet den Ablauf und legt die Abschlussprüfung fest.

Konfiguration wird Produkterlebnis

Ein Mandant. Mehrere Identitätsquellen.

Ein Mandant unterstützt mehrere konfigurierte Identitätsquellen. Die Abbildung zeigt zwei Beispiele: lokale Konten und Unternehmensidentität als Anmeldeoptionen der fiktiven Anwendung Customer Portal.

Ein Mandant. Mehrere Identitätsquellen.A: Alpine account im Admin UI entspricht Continue with Alpine account. B: Alpine corporate identity entspricht Continue with Alpine corporate identity. Die vergrösserte Name-Spalte stammt aus der darüber gezeigten Konfiguration.Konfiguration / MandantenbeziehungenDetail: Name-Spalte derselben AufnahmeBeispielanwendung / Customer PortalAABB
Konfiguration / Mandantenbeziehungen
Mandantenbeziehungen in ProAuth Admin, grosse Ansicht öffnen
Detail: Name-Spalte derselben Aufnahme
Alpine account · Alpine corporate identity
Beispielanwendung / Customer Portal
Continue with Alpine account · Continue with Alpine corporate identity

A Alpine account

Lokale Anmeldung mit ProAuth-verwalteten Identitäten.

B Alpine corporate identity

Unternehmensanmeldung mit dem konfigurierten externen Identity Provider.

Echte ProAuth-Oberflächen · Produktvorschau · Fiktive Beispieldaten. A/B ordnet die angezeigten Einträge zu; die Linien zeigen keinen Netzwerkverkehr.

Das Identitätsmodell

Eine Integration. Mandantenspezifische Beziehungen.

Ihre SaaS-Anwendung ist Client von ProAuth. ProAuth verbindet den Kundenmandanten mit seinen konfigurierten Identitätsquellen.

Identitätsbeziehungen eines SaaS-KundenmandantenDie SaaS-Anwendung ist Client von ProAuth. Im Kundenmandanten verbindet ProAuth lokale Konten und einen externen OpenID Provider; gegenüber diesem ist ProAuth selbst Client. Management API und optionale SCIM-Provisionierung sind separate Beziehungen, kein Anmeldeverkehr.SaaS-AnwendungEine IntegrationProAuthKundenmandant AOpenID Provider /Authorization ServerUpstream: RP / clientKunden-IdPUpstream OIDC providerLokale IdentitätenMandantenverzeichnisOIDC / OAuth 2.0OIDC-FöderationLokale Konten

Admin UI / Management APIMandanten und ihre Identitätsbeziehungen konfigurieren.

SCIM 2.0 optionalSeparate Provisionierung durch kundenseitige Systeme.

Identitätsbeziehungen eines SaaS-KundenmandantenDie SaaS-Anwendung ist Client von ProAuth. Im Kundenmandanten verbindet ProAuth lokale Konten und einen externen OpenID Provider; gegenüber diesem ist ProAuth selbst Client. Management API und optionale SCIM-Provisionierung sind separate Beziehungen, kein Anmeldeverkehr.SaaS-AnwendungOIDC / OAuth clientProAuthOpenID Provider /Authorization ServerUpstream: RP / clientKundenmandant AProAuthBenutzerverzeichnisLokale IdentitätenKunden-IdPUpstream OIDCExterner ProviderOIDC / OAuth 2.0Lokale KontenOIDC-Föderation

Admin UI / Management APIMandanten und ihre Identitätsbeziehungen konfigurieren.

SCIM 2.0 optionalSeparate Provisionierung durch kundenseitige Systeme.

Ein Kundenmandant als Beispiel. Laufzeit-Authentifizierung, Management und optionale Provisionierung sind separate Beziehungen. Attributzuordnungen für SCIM werden beim vorgeschalteten Provisionierungsanbieter konfiguriert.

Was Ihr Team gewinnt

Unterschiedliche Kunden bedienen
Konfigurieren Sie mehrere Mandanten und Identitätsquellen in einem ProAuth-Deployment.
Onboarding wiederholbar machen
Ihre Werkzeuge wenden unterstützte Konfiguration zur Laufzeit über die Management API an.
Die Grundlage selbst steuern
Wählen Sie Hosting und Branding und planen Sie mit einem benutzerunabhängigen Lizenzbudget.

Verantwortung bleibt sichtbar

Unternehmensanforderungen erfüllen, ohne den Identity-Stack selbst zu bauen

Anmeldeanforderungen und Edition

Mandantenspezifische Authentifizierungseinstellungen und Login-Ansichten ermöglichen unterschiedliche Anmeldeanforderungen und Erscheinungsbilder. SCIM kann Verzeichnisinformationen bereits vor der ersten föderierten Anmeldung provisionieren. SCIM und mandantenspezifische Login-Ansichten gehören zur Enterprise Edition.

Anwendungsberechtigungen

Ihre Anwendung bleibt für Mandantenzugehörigkeit, fachliche Berechtigungen und Datenzugriff verantwortlich. Föderation legt diese Regeln nicht automatisch fest.

Datenbanken und Wiederherstellung

Eine konfigurierte Benutzerverzeichnis-Instanz besitzt eine eigene Datenbank. Wenn der optionale Datenbank-Deployment-Worker aktiviert und passend berechtigt ist, kann er diese bereitstellen. Das Backup lässt sich separat verwalten; zur Wiederherstellung eines vollständigen SaaS-Mandanten gehören zusätzlich die relevanten Anwendungs- und Konfigurationsdaten.

Wachstum und neue Anforderungen planen

Lizenzierung und Betrieb

Die Enterprise-Lizenzierung bietet benutzerunabhängige Lizenzpreise im vereinbarten Deployment-Umfang. Infrastruktur und Betrieb werden separat geplant. Sie wählen auch den Betriebsort von ProAuth, wenn sich Ihre Hosting-Anforderungen verändern. Jede Lizenz deckt ein installiertes Produktivsystem mit unbegrenzten Laufzeitreplikas und zugehörigen Dev/Test-Umgebungen inklusive QA, Staging und CI/CD ab. Erworbene Funktionen und Konfigurationskontingente gelten unabhängig pro Umgebung; separate Produktivinstallationen benötigen separate Lizenzen.

Wechsel der Identitätsquelle

Wechselt ein bestehender Mandant die Identitätsquelle, müssen Konten zugeordnet und Anwendungszugriffe geprüft werden. Das logische Benutzermodell und die APIs von ProAuth liefern Integrationsmöglichkeiten dafür. Es handelt sich um eine geplante Änderung, die nicht automatisch durch das Hinzufügen eines Providers abgeschlossen ist.

Die Integration vertiefen.

EinführungsleitfadenBrowser- und API-Sicherheit stärken

Planen Sie Ihren nächsten Kunden.

Gehen Sie das Onboarding eines Kunden mit lokalen Konten und eines Kunden mit Unternehmensföderation durch. Ordnen Sie die Schritte dem Benutzer, seinem IT-Administrator, Ihren Werkzeugen und Ihrem Support zu.

Ihren Kunden-Onboarding-Ablauf besprechenMandantenkonfiguration ansehen

Bildansicht