Zum Inhalt springen

Anbieter und Identitäten in Jitterbit App Builder

Übersicht

Jede App Builder-Anwendung, jede Datenquelle und jeder Webservice benötigt eine Möglichkeit zu bestätigen, wer oder was eine Anfrage stellt, und um zu kontrollieren, was dieser Anfragesteller tun darf. App Builder verwaltet beides über Sicherheitsanbieter – unabhängig konfigurierbare Module, die man aktiviert und einrichtet, um sie der eigenen Umgebung anzupassen, anstatt ein einzelnes eingebautes Anmeldesystem zu nutzen. Beispielsweise könnte ein Sicherheitsanbieter einen Benutzernamen und ein Passwort gegen App Builders eigene Benutzertabelle prüfen, ein anderer könnte einen API-Schlüssel validieren, den ein externes System sendet, und ein dritter könnte die Entscheidung ganz an einen externen Identitätsservice wie Salesforce oder einen SSO-Anbieter delegieren.

Einige Sicherheitsanbieter unterstützen auch Identitäten: Datensätze, die ein Benutzerkonto oder eine Gruppe, die von einem externen System wie einem externen Identitätsanbieter oder einer Datenquelle definiert wird, mit seinem entsprechenden App Builder-Benutzer oder seiner Sicherheitsgruppe verknüpfen. Eine Identität ermöglicht es App Builder, einen Benutzer, der sich über einen externen Anbieter anmeldet, als spezifischen, bereits vorhandenen App Builder-Benutzer zu erkennen, anstatt jede externe Anmeldung als unbekannt zu behandeln.

Diese Seite behandelt:

Anbieter

Nicht alle Sicherheitsanbieter erfüllen dieselbe Aufgabe. Je nach Typ kann ein Sicherheitsanbieter eine oder mehrere der folgenden Rollen erfüllen:

  • Benutzerauthentifizierung: Bestätigt die Identität einer Person, die sich in einer App Builder-Anwendung anmeldet.
  • Datenquellauthentifizierung: Bestätigt die Identität, die App Builder selbst präsentiert, wenn es sich mit einer externen Datenquelle verbindet, wie einer Datenbank oder einer Drittanbieter-API.
  • Sicherheit auf Verbindungsebene: Sichert die zugrunde liegende Verbindung zwischen App Builder und einer Datenquelle, unabhängig von der zur Authentifizierung verwendeten Identität.
  • Autorisierungsrichtlinien: Regelt, was ein bereits authentifizierter Benutzer oder eine Verbindung tun darf, im Unterschied zur Bestätigung, wer er ist.

Jeder konfigurierte Sicherheitsanbieter definiert einen eigenen Satz von Parametern, die der Siteadministrator so festlegt, dass sie Ihrer Umgebung entsprechen. App Builder wird mit einer Standardkonfiguration ausgeliefert, die bereits eine Anfangsserie von Sicherheitsanbietern aktiviert, sodass die Authentifizierung in der Regel sofort funktioniert. Administratoren können diese bei Bedarf anpassen, deaktivieren oder ergänzen. Man kann auch Sicherheitsanbieterkonfigurationen importieren und exportieren.

Standard-Anbietertypen

App Builder wird mit den folgenden Standard-Anbietertypen ausgeliefert, von denen jeder ein bestimmtes Authentifizierungs- oder Autorisierungsschema abdeckt. Wählen Sie den Namen eines Anbieters, um auf sein Konfigurationshandbuch zuzugreifen.

Anbietertyp Beschreibung
Active Directory (AD) Formularbasierter Authentifizierungsanbieter.
API-Schlüssel REST-API-Authentifizierungsanbieter.
Autorisierungsserver Ermöglicht es App Builder, als OAuth-2.0- und OpenID Connect (OIDC)-Autorisierungsserver zu fungieren.
HTTP Authentifiziert HTTP-Clientanfragen an REST-APIs.
Integrated Windows Authentication (IWA) SSO-Schema für Active Directory-Domänen.
Jitterbit Harmony Authentifiziert HTTP-Anfragen an Jitterbit API Manager-Endpunkte.
JWT SSO Benutzerdefiniertes Single-Sign-On-Protokoll (SSO).
Lokaler Benutzer Formularbasierter Authentifizierungsanbieter.
OAuth OAuth-Autorisierungsanbieter.
OData OData-Datenquellenauthentifizierungsschemas.
OpenID Connect Ermöglicht Unterstützung für OpenID Connect 1.0.
URL umschreiben Stellt eine URL wieder her, die von einem Reverse Proxy umgeschrieben wurde.
Salesforce Salesforce-Authentifizierung und Autorisierung mit OAuth2.
SAML SAML Single Sign-On (SSO).
SAML-Identitätsanbieter SAML Single Sign-On (SSO)-Authentifizierung.
SAP OData Services SAP NetWeaver Gateway OData Service-Authentifizierungsschemas.
SuccessFactors OData SuccessFactors OData-Webservice-Authentifizierungsschemas.
SuccessFactors-Passwort Formularbasierter Benutzerauthentifizierungsanbieter.
Benutzerbereitstellung Programmatische Benutzerregistrierung.
Web Access Management (WAM) SSO-Schema für ältere Web Access Management-Systeme.
WS-Federation WS-Federation SSO.

Web-Service-Zuordnungen

Ein Web-Service ist in diesem Kontext ein Endpunkt, den externe Systeme programmatisch aufrufen, im Gegensatz zu einer Seite, die eine Person besucht. Seit App Builder 4.67 müssen drei Typen von Web-Services jeweils explizit mit spezifischen, einzeln konfigurierten Anbietern verknüpft werden, denen die Authentifizierung ihrer Anfragen erlaubt ist. Zuvor konnte jeder aktivierte Anbieter eines geeigneten Typs Anfragen an jeden Web-Service authentifizieren, unabhängig vom Typ.

Web-Service Pfad Geeignete Anbietertypen Authentifizierung konfigurieren
REST API /rest/v1 API-Schlüssel, HTTP, Authorization Server Jitterbit App Builder-App als REST-API-Endpunkt veröffentlichen
Webhook /webhook/v1 API-Schlüssel, HTTP, Authorization Server Webhooks in Jitterbit App Builder
App Builder Connector /connect/v1 API-Schlüssel, HTTP, Authorization Server App Builder-Connector in Jitterbit App Builder

Jede Web-Service-Instanz (jeder einzelne REST-Endpunkt, Webhook-Endpunkt oder Remote-Connector-Anwendung) wird mit spezifischen, einzeln konfigurierten Anbietern dieser Typen verknüpft, nicht nur mit dem Typ allgemein; die verlinkten Seiten beschreiben, wie man diese Verknüpfung herstellt. Beim Upgrade von einer früheren App-Builder-Version verknüpft eine Migration automatisch jeden vorhandenen Anbieter eines geeigneten Typs mit jedem vorhandenen Web-Service des entsprechenden Typs, sodass bestehende Integrationen ohne manuelle Neukonfiguration authentifiziert werden. Ein Web-Service, der nach dem Upgrade auf App Builder 4.67 erstellt wird, wird nicht automatisch mit einem Anbieter verknüpft und authentifiziert keine Anfragen, bis man explizit einen verknüpft.

Die oben verlinkten Schritte zur Authentifizierung konfigurieren werden aus der Anwendung selbst heraus ausgeführt, was nur für eine Anwendung funktioniert, die man noch bearbeiten kann. Bei einer versiegelten Anwendung, die nicht mehr von innen heraus geändert werden kann, siehe Versiegelte Anwendungs-Web-Services unten.

Versiegelte Anwendungs-Web-Services

Das Versiegeln einer Anwendung, wie es geschieht, wenn sie in eine QA- oder Produktivumgebung verschoben wird, blockiert jede Änderung daran von innen heraus, einschließlich der Pro-Endpunkt-Web-Service-Zuordnungen oben.

Bei einer versiegelten Anwendung, die einen Web-Service verfügbar macht, verknüpft man ihre Sicherheitsanbieter stattdessen von außerhalb der App aus, über Anwendungen verwalten. Gehen Sie zu IDE > Sicherheitsanbieter, wählen Sie dann unter Benutzerauthentifizierung die Option Mehr > Anwendungen verwalten aus, und klicken Sie auf das -Symbol in der Web-Service-Spalte der Anwendung. Dies öffnet denselben, oben beschriebenen Dialog Authentifizierungsanbieter.

Seit App Builder 4.68 wird dieses Symbol auch für die Vinyl - Release Management-Anwendung angezeigt, die integrierte Systemanwendung, die die REST-API nutzt, die Einklick-Bereitstellung auf dem Ziel-(QA- oder Produktiv-)System verwendet.

Standardauthentifizierung

Jede Anwendung, ob benutzererstellt oder eine integrierte Systemanwendung, verfügt über einen Standardauthentifizierungs-Anbieter: der Anbieter, der in Kombination mit der Redirect On Challenge-Option des Anbieters verwendet wird, um einen nicht authentifizierten Benutzer zu einem Anbieter umzuleiten, wenn dieser versucht, auf eine geschützte Seite zuzugreifen. Gehen Sie zu IDE > Sicherheitsanbieter, wählen Sie dann unter Benutzerauthentifizierung die Option Mehr > Anwendungen verwalten aus, klicken Sie auf das Bearbeiten-Symbol für die Anwendung, wählen Sie einen Anbieter im Feld Standardauthentifizierung aus, und klicken Sie auf Fortfahren.

Identitätsverwaltung

Wenn ein Sicherheitsanbieter die Authentifizierung an ein externes System delegiert, ob es sich um einen externen Identitätsanbieter wie Salesforce oder SAML SSO handelt oder um eine externe Datenquelle, benötigt App Builder eine Möglichkeit, das, was das externe System über den Benutzer mitteilt, in seine eigenen Begriffe zu übersetzen: ein spezifisches App-Builder-Benutzerkonto und optional die App-Builder-Sicherheitsgruppen, aus denen die Berechtigungen dieses Benutzers stammen sollten. In diesem Abschnitt werden die beiden Mechanismen behandelt, die App Builder nutzt, um diese Übersetzung vorzunehmen:

  • Identitäten, die ein externes Benutzerkonto auf einen App Builder-Benutzer abbilden.
  • Anbietergruppen, die eine externe Gruppe, Rolle oder einen Bereich auf eine App Builder-Sicherheitsgruppe abbilden, sodass die Berechtigungen eines Benutzers von seiner externen Gruppenmitgliedschaft abgeleitet werden können, anstatt jeden Benutzer einzeln zuzuweisen.

Identitäten

Eine Identität verbindet ein externes Benutzerkonto, das von einem bestimmten Sicherheitsanbieter gemeldet wird, mit einem App Builder-Benutzer. Wenn dieser Anbieter eine Anfrage im Namen eines externen Kontos authentifiziert, benötigt App Builder eine entsprechende Identität, um zu wissen, welchem eigenen Benutzer das Konto entspricht. Ohne eine solche kann App Builder nicht feststellen, welcher App Builder-Benutzer das externe Konto darstellt. Ein Benutzer kann nur eine Identität pro Sicherheitsanbieter haben, kann aber separate Identitäten für verschiedene Anbieter haben, zum Beispiel wenn dieselbe Person sich sowohl über Salesforce als auch über SAML SSO anmelden kann.

Identitäten verfügen über die folgenden Eigenschaften:

  • Anbieter: Der Sicherheitsanbieter (Benutzer oder Datenquelle), der die Identität besitzt.
  • Name: Der eindeutige Benutzername, der vom Sicherheitsanbieter zugewiesen wird. Bei der Authentifizierung gibt ein externer Identitätsanbieter normalerweise einen Satz von Claims zurück – Informationen über den Benutzer, wie Name oder eindeutige ID –, die im Authentifizierungstoken oder in der Assertion enthalten sind. Diese Eigenschaft entspricht dem Name-Claim.
  • Identifier: Ein eindeutiger, unveränderlicher Identifier, der vom Sicherheitsanbieter zugewiesen wird und dem NameIdentifier-Claim entspricht. Im Gegensatz zu Name ist dieser Parameter optional, wird aber empfohlen, wenn der Anbieter ihn unterstützt, da er sich nicht ändert, auch wenn sich der Name oder Benutzername des Benutzers später ändern.

Identitäten sind erforderlich, wenn man die Benutzerauthentifizierung an externe Sicherheitsanbieter wie Salesforce oder SAML Single Sign-On (SSO) delegiert. Um die Anmeldung zu vervollständigen, nimmt App Builder die vom Anbieter bereitgestellten Claims und sucht nach einer übereinstimmenden Identität. Zuerst wird der NameIdentifier-Claim überprüft, und falls keine Übereinstimmung gefunden wird, wird auf den Name-Claim zurückgegriffen.

Identitäten spielen auch bei der Authentifizierung von Datenquellen eine Rolle. Die meisten Datenquellenverbindungen authentifizieren sich als ein einzelnes, gemeinsames Dienstkonto, was bedeutet, dass jeder App Builder-Benutzer mit denselben Anmeldeinformationen auf die Datenquelle zugreift. Einige Datenquellen unterstützen jedoch benutzerbeschränkte Authentifizierung, wobei sich die Verbindung stattdessen als der spezifische angemeldete App Builder-Benutzer authentifiziert. Für diese verwendet der Sicherheitsanbieter den Name der Identität, wenn einer für den Benutzer definiert ist, und greift andernfalls auf den App Builder-Benutzernamen zurück. Der Identifier der Identität wird für diesen Zweck nicht verwendet.

Anbietergruppen

Über einzelne Identitäten hinaus kann ein externer Anbieter auch seine eigenen Sicherheitsgruppen definieren, manchmal auch Rollen oder Bereiche genannt, die mehrere Benutzer zusammenfassen, zum Beispiel eine Salesforce-Rolle „Sales Managers" oder eine SAML IdP-Gruppe „Finance". Anstatt Berechtigungen einzelnen Benutzern über ihre Identität zuzuweisen, kann ein Sicherheitsadministrator jede dieser externen Gruppen einer einzelnen App Builder-Sicherheitsgruppe zuordnen, sodass jeder Benutzer, der zur externen Gruppe gehört, automatisch die der entsprechenden App Builder-Sicherheitsgruppe gewährten Berechtigungen erbt.

Sicherheitsanbietergruppen haben die folgenden Eigenschaften:

  • Anbieter: Der Sicherheitsanbieter (Benutzer oder Datenquelle), zu dem die Gruppe gehört.
  • Identifier: Der eindeutige Name, der der Gruppe vom Sicherheitsanbieter zugewiesen wird.
  • Gruppe: Die App Builder-Sicherheitsgruppe, der die Sicherheitsanbietergruppe zugeordnet ist.

Registrierung

Bevor eine Sicherheitsanbietergruppe zugeordnet werden kann, muss sie zunächst in App Builder als Datensatz existieren. Sicherheitsanbietergruppen können auf zwei Arten registriert werden:

  • Manuell: Administratoren melden sich bei App Builder an und fügen Sicherheitsanbietergruppen direkt hinzu. Dies ist normalerweise für Datenquellen-Sicherheitsanbieter erforderlich, die keine Möglichkeit haben, ihre Gruppen App Builder selbst zu melden.
  • Automatisch: App Builder registriert neue Sicherheitsanbietergruppen spontan während des Benutzerauthentifizierungsprozesses und aktualisiert gleichzeitig die Gruppenmitgliedschaft des Benutzers. Dies wird von den Sicherheitsanbietern SAML und WS-Federation unterstützt, aber nur, wenn dies explizit mithilfe des Flags Supplies Group Membership des jeweiligen Anbieters aktiviert wird.

Zuordnung

Unabhängig davon, wie eine Sicherheitsanbietergruppe registriert ist, lässt sich diese einer App Builder-Sicherheitsgruppe zuordnen. Jede Sicherheitsanbietergruppe lässt sich einer und nur einer App Builder-Sicherheitsgruppe zuordnen; mehrere Sicherheitsanbietergruppen können jedoch derselben App Builder-Sicherheitsgruppe zugeordnet werden.

Mitgliedschaft

Eine Sicherheitsanbietergruppe erweitert die App Builder-Sicherheitsgruppenmitgliedschaft eines Benutzers, anstatt diese zu ersetzen. Bei der Berechnung der Zugriffsrechte eines Benutzers berücksichtigt App Builder sowohl die Sicherheitsgruppen, denen der Benutzer direkt angehört, als auch alle Sicherheitsgruppen, denen der Benutzer durch eine zugeordnete Sicherheitsanbietergruppe angehört.