Mit generischem REST integrieren

Das generische REST-orchestrierte System bietet eine Lösung zur Integration von Oracle Access Governance in REST-basierte identitätsbezogene Systeme. Ein REST-basiertes identitätsbezogenes System ist ein beliebiges System, das seine REST-APIs oder -Schnittstellen für das Identitätsmanagement bereitstellt.

Generisches REST-Orchestriertes System - Überblick

Das generische REST-Orchestrierungssystem bietet folgende Features:
  • Vollständiger/inkrementeller Dataload für autoritative Quellen oder verwaltete Systeme
  • Bereitstellung in Echtzeit
  • Cloud-native serverlose Funktionsintegration zur Definition von REST-basierten identitätsbezogenen Systemschemas, Anforderungs-, Antwort- und Testvorlagen

Das generische REST-Orchestrierungssystem unterscheidet sich von anderen Definitionen für Schema, Anforderung und Antwort nicht. Für andere orchestrierte Systeme sind Schema-, Anforderungs-, Antwort- und Testvorlagen für die autorisierende Quelle oder das verwaltete System vorab geladen. Sie können generische REST-orchestrierte Systeme auf jedes REST-basierte identitätsbezogene System anwenden. Schema-, Anforderungs-, Antwort- und Testvorlagen werden zur Laufzeit geladen und nicht beim Erstellen des orchestrierten Systems.

Für jede autoritative Quelle oder jedes verwaltete System müssen Sie die folgenden Vorlagen erstellen:
  • grc-schema-template: Diese Vorlage definiert das Schema für die autoritative Quelle oder das verwaltete System, das Sie integrieren möchten.
  • grc-request-template: Diese Vorlage definiert das Anforderungsformat (Header, URL, Anforderungsparameter, Anforderungsbody), das zum Aufrufen der API für die autoritative Quelle oder das verwaltete System erforderlich ist, um Identitätsdaten anzufordern.
  • grc-response-template: Diese Vorlage definiert das Antwortformat für Identitäts- und Accountdaten.
  • grc-test-template: Diese Vorlage definiert eine API, mit der die Konnektivität zwischen Oracle Access Governance und der zuverlässigen Quelle oder dem verwalteten System getestet wird.
Wenn ein Vorgang aufgerufen wird, werden die folgenden Parameter an OCI Functions übergeben.
  • Name des orchestrierten Systems
  • Entitätsname (Identität oder Konto)
  • Vorgangsname

Die OCI-Funktion wird aufgerufen und gibt eine JSON-Datei mit den für das orchestrierte System relevanten Vorlagen zurück.

Voraussetzungen

Bevor Sie ein generisches REST-Orchestriertes System installieren und konfigurieren, sollten Sie die folgenden Voraussetzungen und Aufgaben berücksichtigen.

Zertifizierte Komponenten

Das verwaltete System kann eines der folgenden sein:

  • Jedes identitätsbezogene System, das REST-Services unterstützt

Unterstützte Modi

Generisches REST-Orchestriertes System unterstützt die folgenden Konfigurationsmodi:

  • Autoritative Herkunft
  • Verwaltetes Systeme

Vom generischen REST-Orchestrierungssystem unterstützte Anwendungsfälle

Ein generisches REST-orchestriertes System kann verwendet werden, um Identitätsdaten aus einem REST-Service in Oracle Access Governance zu integrieren und dann Identitäten in einem integrierten Zyklus mit den restlichen identitätsbezogenen Systemen in Ihrem Unternehmen effizient zu verwalten.

Betrachten Sie als Beispiel für einen geschäftlichen Anwendungsfall ein führendes Logistikunternehmen mit mehr als 20 Cloud-Anwendungen. Die meisten dieser Cloud-Anwendungen sind jetzt ineffizient, da Daten in diesen Anwendungen manuell eingegeben und mit Kalkulationstabellen oder benutzerdefinierten Prozessflüssen verwaltet werden. Daher möchte dieses Unternehmen seine Cloud-Anwendungen in Oracle Access Governance integrieren, um seine Abläufe zu optimieren, die Effizienz seiner Organisation zu steigern und gleichzeitig die Betriebskosten zu senken. Es gibt zwei Ansätze für die Integration dieser Cloud-Anwendungen in Oracle Access Governance. Ein Ansatz besteht darin, für jede dieser Anwendungen einen Point-to-Point-Connector bereitzustellen. Die Nachteile dieses Ansatzes sind wie folgt:
  • Verbesserter Zeit- und Arbeitsaufwand für die Identifizierung und Bereitstellung eines Point-to-Point-Connectors für jede Anwendung.

  • Erhöhter Verwaltungs- und Wartungsaufwand für die Verwaltung von Connectors für jede Anwendung.

  • Nichtverfügbarkeit von Point-to-Point-Konnektoren für alle Anwendungen. In einem solchen Szenario müssen Sie benutzerdefinierte Connectors entwickeln, die den Zeit- und Arbeitsaufwand für die Entwicklung, Bereitstellung und den Test des benutzerdefinierten Connectors erhöhen.

Eine Alternative zu diesem Ansatz ist die Verwendung des generischen REST-Orchestrierten Systems, um alle Cloud-Anwendungen in Oracle Access Governance zu integrieren. Das generische REST-Orchestrierungssystem bietet die Möglichkeit, Accounts über alle Cloud-Anwendungen hinweg zu verwalten, ohne zusätzliche Ressourcen und Zeit für die Erstellung benutzerdefinierter Connectors für jede Cloud-Anwendung aufwenden zu müssen.

Das generische REST-orchestrierte System unterstützt Unternehmen bei der Integration von Oracle Access Governance in verwaltete Systeme für die Identitäts-Governance. Diese verwalteten Systeme umfassen jede Anwendung, die REST-APIs wie SaaS, PaaS, selbst entwickelte Anwendungen usw. bereitstellt.

Im Folgenden finden Sie einige Beispielszenarios, in denen das generische REST-Orchestrierte System verwendet wird:

  • Benutzerverwaltung

    Mit dem generischen REST-orchestrierten System können Sie Personen verwalten, die auf Ressourcen zugreifen können, indem Sie sie als Identitäten in Oracle Access Governance definieren und sie Identitäts-Collections und Rollen zuweisen. Identitäten werden aus jedem autoritativen orchestrierten System wie generischem REST beim Dataload erstellt.

  • Zugriffskontrolle

    Das generische REST-orchestrierte System verwaltet die Zugriffskontrolle über Identitäts-Collections, Rollen, Zugriffs-Bundles und Policys. Je nach verwendetem orchestriertem System können Sie den Zugriff mit Oracle Access Governance-Selfservicefeatures verwalten, insbesondere Zugriff anfordern. Beispiel: Sie können das generische REST-orchestrierte System verwenden, um den Zugriff auf ein System basierend auf vordefinierten Zugriffs-Policys in Oracle Access Governance automatisch zuzuweisen oder zu entziehen. Wenn neue Benutzer einer bestimmten Rolle hinzugefügt werden, erhalten sie automatisch entsprechenden Zugriff auf die Systeme, die von der Zugriffsrichtlinie abgedeckt werden.

OCI Serverless-Funktion für die Verbindung mit einem REST-basierten Identity Aware-System einrichten

Das über die generischen REST-Connector orchestrierten System erfordert Unterstützung von OCI Serverless Functions, um eine Verbindung zu REST-basierten identitätsbewussten Systemen herzustellen.

Informationen zum Einrichten von OCI Functions zur Verwendung mit dem generischen Restorchestrierungssystem finden Sie unter OCI Serverless-Funktion für die Verbindung mit dem REST-basierten Identity Aware System einrichten.

Konfigurieren

Sie können eine Integration zwischen REST-basierten identitätsbezogenen Systemen und Oracle Access Governance einrichten, indem Sie Details zu OCI Functions und Vorlagen eingeben, um das REST-basierte System zu integrieren. Verwenden Sie dazu die Funktion "Orchestriertes System", die in der Oracle Access Governance-Konsole verfügbar ist.

Richten Sie eine Integration zwischen REST-basierten identitätsbezogenen Systemen und Oracle Access Governance ein, indem Sie Details zu OCI Functions und Vorlagen zur Integration des REST-basierten Systems eingeben. Verwenden Sie die Funktionalität des orchestrierten Systems in der Oracle Access Governance-Konsole.

Oracle Access Governance verwendet den Resource Principal, um auf die OCI-Funktionen zuzugreifen und sie aufzurufen. Wenn ein orchestriertes System vorhanden ist und Sie migrieren müssen, finden Sie weitere Informationen unter API-Schlüsselzugriff auf Resource Principal migrieren.

Zur Seite "Orchestrierte Systeme" navigieren

Navigieren Sie zur Seite "Orchestrierte Systeme" der Oracle Access Governance-Konsole, indem Sie die folgenden Schritte ausführen:
  1. Wählen Sie im Oracle Access Governance-Navigationsmenü symbol Navigationsmenü die Option Serviceadministration → Orchestrierte Systeme aus.
  2. Wählen Sie die Schaltfläche Orchestriertes System hinzufügen, um den Workflow zu starten.

System auswählen

Im Schritt System auswählen des Workflows können Sie angeben, welcher Systemtyp integriert werden soll. Mit dem Feld Suchen können Sie das erforderliche System nach Namen suchen. Wählen Sie die Kachel Generischer REST-Connector aus. Wenn Sie diese Kachel auswählen, wird eine Dialogseite angezeigt, auf der die Schritte zur Konfiguration des orchestrierten Systems beschrieben werden. Dazu gehört ein Link zu einer Beispielimplementierung der OCI Functions, die für die Verbindung zu REST-basierten identitätsbezogenen Systemen erforderlich sind. Wenn dies noch nicht geschehen ist, laden Sie die Datei idm-agcs-generic-rest-reference-implementation.zip herunter und entwickeln Ihre eigenen OCI Functions basierend auf diesem Beispiel. Weitere Informationen zur Beispielimplementierung finden Sie unter Setup Sample Implementation. Weitere Informationen zur Entwicklung der erforderlichen OCI Functions finden Sie unter OCI Serverless-Funktion für die Verbindung mit dem REST-basierten Identity Aware System einrichten und Generic Rest Schema Discovery.

Nach der Auswahl wird auf der rechten Seite unter Was ich ausgewählt habe der Wert Generischer REST-Connector angezeigt. Wählen Sie Weiter.

Details eingeben

Geben Sie im Schritt Details hinzufügen des Workflows die Details für das orchestrierte System ein:
  1. Geben Sie im Feld Name einen Namen für das System ein, mit dem Sie eine Verbindung herstellen möchten.
  2. Geben Sie eine Beschreibung für das System in das Feld Beschreibung ein.
  3. Entscheiden Sie, ob dieses orchestrierte System eine zuverlässige Quelle ist und ob Oracle Access Governance Berechtigungen verwalten kann, indem Sie die folgenden Kontrollkästchen aktivieren.
    • Das ist die autoritative Quelle für meine Identitäten

      Wählen Sie unter folgenden Optionen:

      • Quelle der Identitäten und ihrer Attribute: Das System fungiert als Quellidentitäten und zugehörige Attribute. Mit dieser Option werden neue Identitäten erstellt.
      • Nur Quelle von Identitätsattributen: Das System nimmt zusätzliche Details zu Identitätsattributen auf und gilt für vorhandene Identitäten. Mit dieser Option werden keine neuen Identitätsdatensätze aufgenommen oder erstellt.
    • Ich möchte Berechtigungen für dieses System verwalten
    Der Standardwert in jedem Fall ist Nicht ausgewählt.
  4. Wählen Sie Weiter.

Eigentümer hinzufügen

Sie können Ressourcenverantwortung zuordnen, indem Sie primäre und zusätzliche Verantwortliche hinzufügen. Dies steuert Self-Service, da diese Eigentümer dann die Ressourcen verwalten (lesen, aktualisieren oder löschen) können, deren Eigentümer sie sind. Standardmäßig wird der Ressourcenersteller als Ressourceneigentümer angegeben. Sie können einen primären Verantwortlichen und bis zu 20 zusätzliche Verantwortliche für die Ressourcen zuweisen.
Hinweis

Wenn Sie das erste orchestrierte System für Ihre Serviceinstanz einrichten, können Sie Eigentümer erst zuweisen, nachdem Sie die Identitäten im Abschnitt Identitäten verwalten aktiviert haben.
So fügen Sie Eigentümer hinzu:
  1. Wählen Sie im Feld Wer ist der primäre Eigentümer? einen aktiven Oracle Access Governance-Benutzer als primären Eigentümer aus.
  2. Wählen Sie einen oder mehrere zusätzliche Eigentümer in der Liste Wer ist Eigentümer? aus. Sie können bis zu 20 zusätzliche Eigentümer für die Ressource hinzufügen.
Sie können den primären Eigentümer in der Liste anzeigen. Alle Verantwortlichen können die Ressourcen anzeigen und verwalten, für die sie verantwortlich sind.

Accounteinstellungen

Geben Sie im Schritt Accounteinstellungen des Workflows ein, wie Oracle Access Governance Accounts verwalten soll, wenn das System als verwaltetes System konfiguriert ist:
  1. Wenn eine Berechtigung angefordert wird und das Konto noch nicht vorhanden ist, wählen Sie diese Option aus, um neue Konten zu erstellen. Diese Option ist standardmäßig aktiviert. Wenn diese Option ausgewählt ist, erstellt Oracle Access Governance einen Account, wenn kein Account vorhanden ist, wenn eine Berechtigung angefordert wird. Wenn Sie diese Option deaktivieren, werden Berechtigungen nur für vorhandene Konten im orchestrierten System bereitgestellt. Wenn kein Account vorhanden ist, verläuft der Provisioning-Vorgang nicht erfolgreich.
  2. Wählen Sie die Empfänger für Benachrichtigungs-E-Mails aus, wenn ein Account erstellt wird. Der Standardempfänger ist Benutzer. Wenn keine Empfänger ausgewählt sind, werden keine Benachrichtigungen gesendet, wenn Accounts erstellt werden.
    • Benutzer
    • Benutzermanager
  3. Vorhandene Accounts konfigurieren
    Hinweis

    Sie können diese Konfigurationen nur festlegen, wenn dies vom Systemadministrator zulässig ist. Wenn die Einstellungen für die globale Accountbeendigung aktiviert sind, können Anwendungsadministratoren die Einstellungen für die Accountbeendigung nicht auf der orchestrierten Systemebene verwalten.
    1. Wählen Sie aus, was mit Konten zu tun ist, wenn die vorzeitige Beendigung beginnt: Wählen Sie die Aktion aus, die ausgeführt werden soll, wenn eine vorzeitige Beendigung beginnt. Dies geschieht, wenn Sie Identitätszugriffe vor dem offiziellen Austrittsdatum widerrufen müssen.
      • Löschen: Löscht alle Accounts und Berechtigungen, die von Oracle Access Governance verwaltet werden.
        Hinweis

        Wenn ein bestimmtes orchestriertes System die Aktion nicht unterstützt, wird keine Aktion ausgeführt.
      • Deaktivieren: Deaktiviert alle Konten und deaktiviert Berechtigungen, die von Oracle Access Governance verwaltet werden.
        • Berechtigungen für deaktivierte Konten löschen: Um einen Restzugriff von Null sicherzustellen, wählen Sie diese Option aus, um direkt zugewiesene Berechtigungen und Policy-berechtigte Berechtigungen bei der Kontodeaktivierung zu löschen.
      • Keine Aktion: Wenn eine Identität von Oracle Access Governance zur vorzeitigen Beendigung gekennzeichnet wird, wird keine Aktion ausgeführt.
    2. Wählen Sie aus, was mit Konten am Austrittsdatum zu tun ist: Wählen Sie die Aktion aus, die während des offiziellen Austritts ausgeführt werden soll. Dies geschieht, wenn Sie Identitätszugriffe am offiziellen Austrittsdatum widerrufen müssen.
      • Löschen: Löscht alle Accounts und Berechtigungen, die von Oracle Access Governance verwaltet werden.
        Hinweis

        Wenn ein bestimmtes orchestriertes System die Aktion Löschen nicht unterstützt, wird keine Aktion ausgeführt.
      • Deaktivieren: Deaktiviert alle Konten und deaktiviert Berechtigungen, die von Oracle Access Governance verwaltet werden.
        • Berechtigungen für deaktivierte Konten löschen: Um einen Restzugriff von Null sicherzustellen, wählen Sie diese Option aus, um direkt zugewiesene Berechtigungen und Policy-berechtigte Berechtigungen bei der Kontodeaktivierung zu löschen.
        Hinweis

        Wenn ein bestimmtes orchestriertes System die Aktion Deaktivieren nicht unterstützt, wird der Account gelöscht.
      • Keine Aktion: Für Accounts und Berechtigungen von Oracle Access Governance wird keine Aktion ausgeführt.
  4. Wenn eine Identität Ihr Unternehmen verlässt, müssen Sie den Zugriff auf ihre Accounts entfernen.
    Hinweis

    Sie können diese Konfigurationen nur festlegen, wenn dies von Ihrem Systemadministrator zulässig ist. Wenn die globalen Einstellungen für die Kontobeendigung aktiviert sind, können Anwendungsadministratoren die Einstellungen für die Kontobeendigung nicht auf der orchestrierten Systemebene verwalten.

    Wählen Sie eine der folgenden Aktionen für den Account aus:

    • Löschen: Löschen Sie alle Accounts und Berechtigungen, die von Oracle Access Governance verwaltet werden.
    • Deaktivieren: Deaktivieren Sie alle Accounts, und markieren Sie Berechtigungen als inaktiv.
      • Berechtigungen für deaktivierte Konten löschen: Löschen Sie direkt zugewiesene und durch Richtlinien erteilte Berechtigungen bei der Kontodeaktivierung, um einen verbleibenden Zugriff zu verhindern.
    • Keine Aktion: Keine Aktion ausführen, wenn eine Identität die Organisation verlässt.
    Hinweis

    Diese Aktionen sind nur verfügbar, wenn sie vom orchestrierten Systemtyp unterstützt werden. Beispiel: Wenn Löschen nicht unterstützt wird, werden nur die Optionen Deaktivieren und Keine Aktion angezeigt.
  5. Wenn alle Berechtigungen für einen Account entfernt werden, z.B. wenn eine Identität zwischen Abteilungen verschoben wird, müssen Sie möglicherweise entscheiden, was mit dem Account zu tun ist. Wählen Sie eine der folgenden Aktionen aus, sofern dies vom orchestrierten Systemtyp unterstützt wird:
    • Löschen
    • Deaktivieren
    • Keine Aktion
  6. Accounts verwalten, die nicht von Access Governance erstellt wurden: Wählen Sie diese Option aus, um Accounts zu verwalten, die direkt im orchestrierten System erstellt werden. Damit können Sie vorhandene Accounts abstimmen und über Oracle Access Governance verwalten.
Hinweis

Wenn Sie das System nicht als verwaltetes System konfigurieren, wird dieser Schritt im Workflow angezeigt, ist jedoch nicht aktiviert. In diesem Fall fahren Sie direkt mit dem Schritt Integrationseinstellungen des Workflows fort.
Hinweis

Wenn Ihr orchestriertes System eine dynamische Schema-Discovery erfordert, wie bei den generischen Integrationen für REST- und Datenbankanwendungstabellen, kann beim Erstellen des orchestrierten Systems nur das Benachrichtigungs-E-Mail-Ziel (Benutzer, Benutzer) festgelegt werden. Sie können die Deaktivierungs-/Löschregeln für Mover und Abgänger nicht festlegen. Dazu müssen Sie das orchestrierte System erstellen und dann die Accounteinstellungen aktualisieren, wie unter Einstellungen für orchestrierte Systemaccounts konfigurieren beschrieben.

Konfigurieren

Geben Sie im Schritt Konfigurieren des Workflows die Konfigurationsdetails ein, die erforderlich sind, damit Oracle Access Governance über den generischen REST-Connector eine Verbindung zum System herstellen kann.

  1. Wie lautet die OCI-Mandanten-OCID der OCI-Funktion?: Geben Sie die OCID (Oracle Cloud-ID) für Ihre OCI-Funktion ein. Siehe Hier erhalten Sie die OCID des Mandanten und der Benutzer-OCID. Beispiel: ocid1.oc1..aabdgsegsccawmw2o6qraopae7egmlochlopclhnwxq6pctu6oocgn.
  2. Wie lautet der Regionscode der OCI-Funktion?: Geben Sie die Hauptregion für den OCI-Zielmandanten mit der Regions-ID ein. Beispiel: Für US East (Ashburn) lautet die Regions-ID us-ashburn-1. Siehe Die Hauptregion und Wie finde ich die Hauptregion meines Mandanten?
  3. Wie lautet die Compartment-ID der OCI-Funktion?: Geben Sie die Compartment-ID für die zu integrierende Funktion ein.
  4. Wie lautet der Anwendungsname der OCI-Funktion?: Geben Sie den Anwendungsnamen der Funktion ein, die Sie integrieren möchten.
  5. Funktionsversion: Geben Sie die Funktionsversion der Funktion ein, die Sie integrieren möchten.
  6. Dauer (in Minuten) für die TTL für den Anforderungsvorlagencache: Dauer, für die die Anforderungsvorlage gecacht werden soll. Wenn die Zeit auf 0 gesetzt ist, wird kein Caching durchgeführt. Wenn der Cache abläuft, wird die OCI-Funktion aufgerufen, um die neue Vorlage abzurufen. Die Cachezeit muss kleiner als die Tokenablaufzeit sein, um gelöschte Verbindungen aufgrund eines abgelaufenen Tokens zu vermeiden.
  7. Dauer (in Minuten) für den Antwortvorlagencache: Dauer, für die die Antwortvorlage gecacht werden soll. Wenn die Zeit auf 0 gesetzt ist, wird kein Caching durchgeführt. Wenn der Cache abläuft, wird die OCI-Funktion aufgerufen, um die neue Vorlage abzurufen. Die Cachezeit muss kleiner als die Tokenablaufzeit sein, um gelöschte Verbindungen aufgrund eines abgelaufenen Tokens zu vermeiden.
  8. Dauer (in Minuten) für den Testvorlagencache: Dauer, für die die Testvorlage gecacht werden soll. Wenn die Zeit auf 0 gesetzt ist, wird kein Caching durchgeführt. Wenn der Cache abläuft, wird die OCI-Funktion aufgerufen, um die neue Vorlage abzurufen. Die Cachezeit muss kleiner als die Tokenablaufzeit sein, um gelöschte Verbindungen aufgrund eines abgelaufenen Tokens zu vermeiden.
  9. Dauer für Schemavorlage (in Minuten): Dauer, für die die Schemavorlage gecacht werden soll. Wenn die Zeit auf 0 gesetzt ist, wird kein Caching durchgeführt. Wenn der Cache abläuft, wird die OCI-Funktion aufgerufen, um die neue Vorlage abzurufen. Die Cachezeit muss kleiner als die Tokenablaufzeit sein, um gelöschte Verbindungen aufgrund eines abgelaufenen Tokens zu vermeiden.
  10. Timeout beim Lesen der Antwort (in Sekunden): Geben Sie einen Ganzzahlwert ein, der die Anzahl der Sekunden angibt, innerhalb derer eine Antwort von der
  11. Verbindungstimeout (in Sekunden): Ein Ganzzahlwert, der die Anzahl der Sekunden angibt, nach denen ein Versuch, die Verbindung zwischen dem Zielsystem und dem Timeout herzustellen, wegen Timeout abgebrochen wird.
  12. Klicken Sie auf Hinzufügen .
  13. Erforderliche OCI-Policys?: Kopieren Sie die genauen Anweisungen im Root-Compartment des relevanten Mandanten. Informationen zum Anwenden der Policys auf den Mandanten finden Sie unter Policys verwalten.

Fertigstellen

Im letzten Schritt, Fertigstellen, können Sie wählen, ob Sie das orchestrierte System weiter konfigurieren möchten, bevor Sie einen Dataload ausführen, oder ob Sie die Standardkonfiguration akzeptieren und einen Dataload initiieren möchten. Wählen Sie eine aus:
  • Anpassen und dann das System für Dataloads aktivieren
  • Aktivieren und die Dataload mit den bereitgestellten Standardwerten vorbereiten

API-Schlüsselzugriff auf Resource Principal-Zugriff migrieren

Wenn Sie bereits über orchestrierte Systeme verfügen, die mit der API-Schlüsselzugriffsmethode eine Verbindung herstellen, sollten Sie möglichst schnell zur Resource-Principal-Zugriffsmethode migrieren.

So migrieren Sie API-Schlüsselzugriff auf Resource Principal:

  1. Navigieren Sie zur Seite Integrationseinstellungen, und befolgen Sie die Anweisungen unter "Orchestrierte Systemintegrationseinstellungen konfigurieren".
  2. Auf der Seite Integrationseinstellungen wird eine Warnung zur Einstellung angezeigt. Klicken Sie auf die Schaltfläche Weitere Informationen zur Migration.
  3. Kopieren Sie die genauen Policys im Root Compartment, wie in der Konsole angezeigt. Weitere Informationen zum Anwenden der Policys finden Sie unter Policy erstellen.
    Hinweis

    Die erforderlichen Policys variieren je nachdem, wo Ihre OCI Functions- und Oracle Access Governance-Instanz gehostet werden (z.B. in demselben Mandanten und in verschiedenen Mandanten).

  4. Nachdem Sie Policys angewendet haben, wählen Sie Integration testen aus, um die Verbindung zu prüfen. Wenn Sie Fehler oder Meldungen haben, prüfen Sie Ihre Konfiguration. Sie können die Migration erst abschließen, wenn der Test erfolgreich war.
  5. Wenn Ihre Verbindung bestätigt wurde, klicken Sie auf die Schaltfläche Migrieren, um die Migration zu starten.
  6. Nach Abschluss der Migration wird eine Bestätigungsmeldung angezeigt
Hinweis

Nachdem Sie die Migration zur Resource-Principal-Methode abgeschlossen haben, können Sie die Prozedur nicht rückgängig machen und die API-Schlüsselmethode in Ihrem orchestrierten System wiederherstellen.

Nach Konfiguration

Nachdem Sie Ihr generisches REST-Orchestriertes System konfiguriert haben, können Sie zur Seite "Orchestriertes System" navigieren und Vorgänge im Aktivitätslog prüfen. Einige der Vorgänge, die angezeigt werden, sind:
  • Schema-Discovery: Das generische REST-orchestrierte System ist zum Entwurfs- und Deployment-Zeitpunkt schemalos. Im Rahmen des Orchestrierungslebenszyklus muss die Schema-Discovery durchgeführt werden, um das orchestrierte System mit Details des Schemas und der Objektklassen für die erforderliche autoritative Quelle oder das verwaltete System zu aktualisieren. Einzelheiten zur Schema-Discovery finden Sie unter Discovery von generischem Restschema.
  • Validieren: Dieser Vorgang führt die folgenden Aufgaben aus:
    • Ruft die Testvorlage auf, die wiederum den in der Vorlage angegebenen Endpunkt aufruft und die Konnektivität mit dem verwalteten System prüft.
    • Ruft die Schemavorlage auf und ruft alle Schemainformationen für das verwaltete System ab, einschließlich Entitys und Attribute.
  • Laden von Lookup-Daten: Wenn Lookups definiert sind, werden die den Lookups entsprechenden Daten geladen.
  • Vollständiges Laden von Daten: Dieser Vorgang lädt die Daten für alle angegebenen Entitys und die Datenaufnahme.