Änderungen in Edge for Private Cloud 4.53.01

Änderungen im Überblick

In Edge for Private Cloud 4.53.01 wurden mehrere Änderungen eingeführt, die die Sicherheit der Plattform verbessern. Dazu gehören aktualisierte Versionen von Software und Bibliotheken. Diese Änderungen wirken sich auf Folgendes aus:

  • OAS-Validierungsrichtlinie (OpenAPI-Spezifikation)
  • Richtlinien, die JSONPath-Abfragen unterstützen
  • Java-Callout-Richtlinie, die auf eingestellten Bibliotheken basiert
  • OpenLDAP

In diesem Abschnitt werden verschiedene Arten von Änderungen beschrieben, die in Version 4.53.01 eingeführt wurden und die Ihre Arbeitsabläufe während oder nach dem Upgrade beeinträchtigen können. Außerdem werden Methoden zur Identifizierung potenzieller Problembereiche sowie Methoden zur Risikominderung oder Problemumgehungen behandelt.

OAS-Validierungsrichtlinie (OpenAPI-Spezifikation)

Kontext

Mit der OASValidation-Richtlinie werden eingehende Anfragen oder Antworten anhand der in der OpenAPI 3.0-Spezifikation (JSON oder YAML) definierten Regeln validiert. In Edge for Private Cloud 4.53.01 wurden Verbesserungen an der OAS-Richtlinie (OpenAPI-Spezifikation) vorgenommen, die sich auf eine strengere und genauere Validierung von API-Antworttexten konzentrieren.

Änderungen

In Edge for Private Cloud 4.53.01 werden zwei wichtige Änderungen an der Art und Weise eingeführt, wie die OAS-Richtlinie API-Antworten validiert. Dadurch wird eine engere Abstimmung mit Ihrer OpenAPI-Spezifikation erreicht:

  • Szenario 1:
    • Bisheriges Verhalten:Wenn für Ihre OpenAPI-Spezifikation ein Antworttext erforderlich war, die tatsächliche Antwort vom Ziel oder der Upstream-Richtlinie jedoch keinen enthielt, wurde dies von der Richtlinie nicht als Validierungsfehler gekennzeichnet.
    • Aktuelles Verhalten: Die Richtlinie gibt in diesem Szenario jetzt korrekt einen Validierungsfehler zurück (z. B. defines a response schema but no response body found), der auf eine Abweichung zwischen der erwarteten und der tatsächlichen Antwort hinweist.
  • Szenario 2:
    • Bisheriges Verhalten:Wenn in Ihrer OpenAPI-Spezifikation explizit angegeben war, dass kein Antworttext erwartet wurde, die tatsächliche Antwort vom Ziel oder der Upstream-Richtlinie jedoch einen Text enthielt, führte die Richtlinie nicht zu einem Fehler.
    • Aktuelles Verhalten: Die Richtlinie führt in diesem Szenario jetzt zu einem Fehler (z. B. No response body is expected but one was found), sodass Antworten dem angegebenen Schema genau entsprechen.

Problembehebung

Suchen Sie nach Proxys oder freigegebenen Abläufen, in denen die OAS-Validierungsrichtlinie mit einem Source-Tag konfiguriert ist, das auf response gesetzt ist, oder die die Antwort einer anderen Richtlinie validieren, die eine Antwort generiert.

Sobald ein Proxy oder ein freigegebener Ablauf identifiziert wurde, muss die Antwort mit der OAS-Spezifikation übereinstimmen. Die Antwort muss sich hinsichtlich des Vorhandenseins oder Fehlens eines Antworttexts strikt an Ihre OpenAPI-Spezifikation halten. Sie können Standard-Apigee-Traces verwenden, um Ihre Traffic-Muster zu prüfen. Wenn das Ziel die Antwort nur zeitweise zurückgibt, verwenden Sie andere Richtlinien, um sie vor der OAS-Richtlinie zu validieren.

  • Wenn in Ihrer OAS-Spezifikationsdatei ein Antworttext definiert ist, muss die Antwort von der Ziel- oder Upstream-Richtlinie immer einen Antworttext enthalten.
  • Wenn in Ihrer OAS-Spezifikationsdatei kein Antworttext definiert ist, darf die Ziel- oder Upstream-Richtlinie keinen senden.

Aktualisieren Sie die OAS-Validierungsrichtlinie oder Ihr Zielverhalten nach Bedarf, bevor Sie das Upgrade auf Private Cloud 4.53.01 durchführen. Sie sollten solche identifizierten Arbeitsabläufe zuerst in Ihren Nicht-Produktionsumgebungen validieren, um das Risiko von Unterbrechungen während des Upgrades des Produktionsclusters zu minimieren.

JSON-Pfad

Kontext

In Edge for Private Cloud 4.53.01 wurde die Verwendung von JSON-Pfadausdrücken in verschiedenen Richtlinien geändert. JSONPath-Ausdrücke können in Richtlinien wie ExtractVariable, RegularExpressionProtection und Data masking verwendet werden, um JSON-Inhalte zu parsen oder Werte in Variablen zu speichern. JSONPath-Ausdrücke können auch in der allgemeinen Nachrichtenvorlagenerstellung verwendet werden, um Variablen während der Proxy-Ausführung dynamisch durch Werte zu ersetzen. Die neuen JSONPath-Ausdrücke und ‑Formate entsprechen den neuesten JSON-Ausdrucksstandards.

Änderungen

Es ist wichtig, vorhandene API-Proxys/freigegebene Abläufe auf Richtlinien zu prüfen, in denen JSONPath-Ausdrücke verwendet werden. Dazu gehören unter anderem die Richtlinie „Variablen extrahieren“, die Richtlinie „Schutz vor regulären Ausdrücken“ oder eine beliebige Richtlinie mit einer Nachrichtenvorlage, die JSONPath verwendet.

Die folgenden JSON-Eingaben werden verwendet, um die Änderungen zu erläutern:

{
  "store": {
    "book": [
      {"category": "reference", "author": "Nigel Rees", "price": 8.95},
      {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
      {"category": "fiction", "author": "Herman Melville", "price": 8.99}
    ],
    "bicycle": {
      "color": "red",
      "book": [
        {"author": "Abc"}
      ]
    }
  }
}
  1. Verhaltensänderung bei JSONPath-Wildcard [*] für Objektwerte

    Das Verhalten des Platzhalters [*] wurde geändert, wenn er für den Zugriff auf alle unmittelbaren Werte eines JSON-Objekts verwendet wird. Bisher wurden mit $.object[*] die unmittelbaren Werte in einem einzelnen JSON-Objekt zurückgegeben. Mit den aktualisierten Bibliotheken ist die Ausgabe jetzt ein Array mit diesen Werten.

    Zum Beispiel $.store[*]:

    Bisheriges Verhalten: 
    {
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}
    Vor der Änderung: 
    [
  [
    {"category": "reference", "author": "Nigel Rees", "price": 8.95},
    {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
    {"category": "fiction", "author": "Herman Melville", "price": 8.99}
  ],
  {
    "color": "red",
    "book": [{"author": "Abc"}]
  }
]
    Aktion:

    Ändern Sie den JSONPath-Ausdruck so, dass er nur auf das übergeordnete Objekt verweist (z. B. $.store), um direkt auf die zuvor abgerufenen Elemente zu verweisen.

  2. Fehler durch nachgestellten Punkt (.) in JSONPath-Pfaden

    JSONPath-Ausdrücke werden strenger validiert. Bisher wurden Pfade, die mit einem ungültigen nachgestellten Punkt enden (z. B. $.path.to.element.), stillschweigend ignoriert und die Abfrage gab weiterhin ein Ergebnis zurück, wenn das vorhergehende gültige Pfadsegment übereinstimmte. In der neuen Version werden solche fehlerhaften Pfade jetzt korrekt als ungültig erkannt und führen zu einem Fehler.

    Beispiel: $.store.book.

    Bisheriges Verhalten: 
    [
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"}
]
    Vor der Änderung: 
    ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'

    Alle vorhandenen Richtlinien, in denen JSONPath-Ausdrücke mit einem unbeabsichtigten nachgestellten Punkt verwendet werden, schlagen jetzt mit einem InvalidPathException fehl.

    Aktion:

    Entfernen Sie den nachgestellten Punkt aus allen JSONPath-Ausdrücken, die damit enden. Ändern Sie beispielsweise $.store.book. in $.store.book.

  3. Änderung der Ausgabestruktur für den rekursiven Abstieg von JSONPath (..)

    Es gibt Änderungen bei der Rückgabe von Ergebnissen, wenn Sie den Operator (..) (rekursiver Abstieg) verwenden, um alle Vorkommen eines benannten Elements zu finden. Bisher wurden alle gefundenen Elemente in einer einzigen Liste zusammengefasst. Die aktualisierten Bibliotheken geben jetzt eine Liste von Listen zurück, wodurch die ursprüngliche Gruppierungsstruktur beibehalten wird, in der Elemente gefunden wurden, anstatt einer einzelnen flachen Liste.

    Beispiel: $..book

    Bisheriges Verhalten: 
    [
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"},
  {"author":"Abc"}
]
    Vor der Änderung: 
    [
  [
    {"category":"reference","author":"Nigel Rees","price":8.95},
    {"category":"fiction","author":"Evelyn Waugh","price":12.99},
    {"category":"fiction","author":"Herman Melville","price":8.99}
  ],
  [
    {"author":"Abc"}
  ]
]
    Aktion:

    Aktualisieren Sie die Logik für die Downstream-Verarbeitung, um die neue Struktur des verschachtelten Arrays zu berücksichtigen. Wahrscheinlich müssen Sie die äußere JSONArray durchlaufen und dann jede innere JSONArray, um auf die einzelnen Elemente zuzugreifen.

  4. JSONPath-Indexierung nach Auswahl oder Filter mehrerer Elemente gibt leeres Array zurück

    Es gibt eine Verhaltensänderung, wenn ein Index (z. B. [0]) direkt nach einer Auswahl mit mehreren Elementen (z. B. [*]) oder einem Filter ([?(condition)]) angewendet wird. Bisher wurde bei solchen Ausdrücken versucht, das Element am angegebenen Index aus den kombinierten Ergebnissen auszuwählen. In der neuen Version geben diese Ausdrücke jetzt ein leeres Array ([]) zurück.

    Beispiel: $.store.book[*][0]

    Bisheriges Verhalten: 
    {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
    Vor der Änderung: 
    []
    Aktion:

    Wenn Sie ein bestimmtes Element aus dem gefilterten Satz filtern und abrufen müssen, verarbeiten Sie das gefilterte Array, das von JSONPath zurückgegeben wird, z. B. $..book[?(@.category == 'fiction')], und übernehmen Sie dann [0] aus dem vorherigen Ergebnis.

  5. Änderung der Ausgabe für negatives Array-Slicing in JSONPath

    In der neuen Version wurde das Verhalten von negativen Array-Slices geändert (z. B. [-2:], [-1:]). Bisher wurde bei der Anwendung eines negativen Slice auf ein Array (Elemente vom Ende des Arrays) in der alten Version fälschlicherweise nur ein einzelnes Element aus diesem Slice zurückgegeben. In der neuen Version wird jetzt korrekt eine Liste (Array) mit allen Elementen zurückgegeben, die in den angegebenen negativen Bereich fallen.

    Beispiel: $.store.book[-2:]

    Bisheriges Verhalten: 
    {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
    Vor der Änderung: 
    [
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
    Aktion:

    Die nachgelagerte Verarbeitungslogik muss jetzt aktualisiert werden, um das zurückgegebene JSON-Array zu durchlaufen und die gewünschte Ausgabe zu erhalten.

  6. JSONPath-Punkt muss vorangestellt werden

    Die Syntax für Elemente, auf die direkt über das Stammverzeichnis zugegriffen wird, wird strenger durchgesetzt. Wenn auf die Elemente direkt über den Stamm ohne vorangestellten Punkt zugegriffen wird (z. B. $propertyelement), gilt diese Syntax jetzt als Fehler und verhindert die Proxybereitstellung.

    Beispiel: $store

    {
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}

    Aktuelles Verhalten:

    Proxy will fail to deploy.

    Aktion:

    Ändern Sie den JSONPath so, dass er den Punkt enthält: $.propertyName (Beispiel: $.store). Dadurch wird der Wert richtig abgerufen.

  7. Dynamische JSONPath-Ausdrücke

    Achten Sie genau auf Richtlinien, in denen der JSONPath-Ausdruck selbst durch eine Variable bereitgestellt wird (z. B. {myJsonPathVariable} oder {dynamicPath}). Der Wert dieser Variablen muss ebenfalls anhand der oben beschriebenen potenziellen Verhaltensänderungen geprüft werden.

Problembehebung

Um das Risiko zu minimieren, ist eine umfassende Strategie erforderlich. Dazu gehört, den geeigneten Aktualisierungspfad auszuwählen und die erforderliche Korrektur für fehlerhafte JSONPath-Ausdrücke anzuwenden.

Wählen Sie die für Sie am besten geeignete Methode für den Upgrade-Pfad aus:

  • Migration ohne Ausfallzeiten

    Bei dieser Strategie werden eine oder mehrere neue Umgebungen bereitgestellt, damit Sie separate Nachrichtenprozessorknoten damit verbinden können. Für solche Nachrichtenknoten kann die Version 4.53.01 installiert werden und sie können Proxys mit modernen JSONPath-Ausdrücken haben. Sie können während des Upgrades verwendet und nach Abschluss des Upgrades außer Betrieb genommen werden. Diese Strategie ist nahtlos, erfordert jedoch die vorübergehende Beschaffung zusätzlicher Message-Processor-Knoten, um ein reibungsloses Upgrade zu ermöglichen. Details:

    • Erstellen Sie eine neue Umgebung und fügen Sie dieser neuen Umgebung neue Message-Processor-Knoten der Version 4.53.01 hinzu.
    • Laden Sie das Proxy-Bundle für die betroffenen Proxys in die neue Umgebung hoch, wenden Sie die im Abschnitt zur Fehlerbehebung beschriebenen erforderlichen Korrekturen an und stellen Sie das aktualisierte Proxy-Bundle in der neuen Umgebung bereit.
    • Leiten Sie den Traffic in die neue Umgebung um und heben Sie die Bereitstellung der betroffenen Proxys in der alten Umgebung auf.
    • Führen Sie ein Upgrade der ursprünglichen Message Processor-Knoten auf Version 4.53.01 durch. Stellen Sie Proxys mit Korrekturen für JSONPath in der ursprünglichen Umgebung bereit.
    • Leiten Sie den Traffic wieder an die alte Umgebung weiter. Diese hat jetzt Message-Prozessoren auf Version 4.53.01 und einen Proxy, der für neue JSONPath-Ausdrücke modernisiert wurde.
    • Löschen und deaktivieren Sie die neue Umgebung und die zugehörigen Knoten.
  • Ausfallzeiten und Upgrade

    Bei dieser Strategie wird die Ausfallzeit für API-Proxys mit fehlerhaften JSONPath-Ausdrücken berücksichtigt. Dazu sind keine zusätzlichen Message Processor-Knoten erforderlich, aber der API-Traffic für betroffene Proxys wird unterbrochen.

    • Identifizieren Sie die betroffenen Proxys mit den betroffenen Richtlinien und erstellen Sie eine neue Überarbeitung für alle betroffenen Proxys.
    • Nehmen Sie die erforderlichen Korrekturen vor, indem Sie die im Abschnitt zur Fehlerbehebung beschriebenen Korrekturen in einer neuen Überarbeitung des Proxys implementieren. Stellen Sie es noch nicht bereit.
    • Sorgen Sie für Ausfallzeiten für den/die betroffenen Proxy(s).
    • Aktualisieren Sie alle Message Processors auf Edge for Private Cloud Version 4.53.01. Hinweis: Die vorhandenen Proxys funktionieren möglicherweise nicht auf den neu aktualisierten Message Processors.
    • Wenn alle Message Processors auf Edge for Private Cloud Version 4.53.01 aktualisiert wurden , stellen Sie die neu erstellte Proxy-Revision mit dem korrigierten JSONPath-Ausdruck bereit.
    • Traffic auf solchen Proxys fortsetzen
  • Proxy vor dem Upgrade neu gestalten

    Sie können den Proxy selbst neu gestalten, bevor Sie auf Edge for Private Cloud 4.53.01 aktualisieren. Anstatt auf bestimmte JSON-Pfadausdrücke zu setzen, können Sie dasselbe Ergebnis mit einer anderen Methode erzielen.

    Wenn Sie beispielsweise eine Richtlinie zum Extrahieren von Variablen mit einem JSON-Pfad verwenden, können Sie die Richtlinie durch eine JavaScript-Richtlinie ersetzen, die ähnliche Daten extrahiert, bevor Sie auf die neuere Version aktualisieren. Nach dem Upgrade können Sie Ihren Proxy wieder so ändern, dass JSON-Pfade mit neueren Formaten verwendet werden.

JavaCallout-Änderungen

Kontext

In Edge for Private Cloud 4.53.00 und früher gab es ein Verzeichnis namens deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated), das eine Reihe von JAR-Bibliotheken enthielt. Diese Bibliotheken waren für die Verwendung in Java-Code in der JavaCallout-Richtlinie verfügbar und konnten direkt oder indirekt von Ihrem benutzerdefinierten Java-Code verwendet werden.

Änderungen

Das eingestellte-Verzeichnis wurde in Edge für die Private Cloud-Version 4.53.01 entfernt. Wenn Ihr Java-Code auf solchen Bibliotheken basiert, schlagen Proxys, die solche Java-Callouts verwenden, fehl, wenn Message-Prozessoren auf Version 4.53.01 aktualisiert werden. Um solche Fehler zu vermeiden, führen Sie die folgenden Schritte aus, bevor Sie die Message-Prozessoren auf Version 4.53.01 aktualisieren.

Problembehebung

  1. Prüfen Sie Ihre JavaCallout-Richtlinien und die zugehörigen JAR-Dateien und stellen Sie fest, ob in einer von ihnen auf Bibliotheken verwiesen wird, die sich im Verzeichnis „deprecated“ Ihrer aktuellen Message-Prozessoren befinden, oder ob solche Bibliotheken verwendet werden. Beachten Sie, dass Java-Callouts möglicherweise JAR-Dateien verwenden, die als Ressourcen auf Organisations- oder Umgebungsebene hochgeladen wurden. Sehen Sie sich auch diese Bibliotheken an.
  2. Nachdem Sie solche veralteten Bibliotheken identifiziert haben , können Sie das Problem mit einer der folgenden Methoden beheben.
    • Ressourcenplatzierung (empfohlen, wenn Sie nur wenige JAR-Dateien / Bibliotheken aus dem eingestellten Verzeichnis haben, auf die von den Java-Callout-JAR-Dateien verwiesen wird)
      • Laden Sie die identifizierten eingestellten JARs als Ressource auf der gewünschten Ebene hoch: API-Proxy-Überarbeitung, Umgebung oder Organisation.
      • Fahren Sie wie gewohnt mit dem Apigee-Software-Upgrade fort.
    • Manuelle Platzierung (empfohlen, wenn Sie eine große Anzahl von JARs / Bibliotheken haben, auf die von den Java-Callout-JARs verwiesen wird)
      • Erstellen Sie auf jedem Knoten des Nachrichtenprozessors ein neues Verzeichnis mit dem Namen external-lib unter dem Pfad $APIGEE_ROOT/data/edge-message-processor/.
      • Kopieren Sie die identifizierten JARs aus dem eingestellten Verzeichnis cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar in das Verzeichnis external-lib:
      • Achten Sie darauf, dass das Verzeichnis und die zugrunde liegenden JAR-Dateien vom Apigee-Nutzer gelesen werden können: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • Fahren Sie wie gewohnt mit dem Apigee-Software-Upgrade fort.

OpenLDAP-Änderung

Kontext

OpenLDAP kann in Edge Private Cloud sowohl für die Authentifizierung als auch für die Autorisierung verwendet werden. In Edge for Private Cloud 4.53.01 wurde die von Apigee bereitgestellte OpenLDAP-Software von Version 2.4 auf Version 2.6 aktualisiert.

Änderungen

In OpenLDAP 2.6 ist der Relative Distinguished Name (RDN) auf etwa 241 Byte/Zeichen begrenzt. Dieses Limit ist ein fester Grenzwert, der nicht geändert werden kann.

Auswirkungen
  • Bei Einträgen mit zu großen relativen Distinguished Names (RDNs) treten Replikations- oder Importfehler auf.
  • Wenn Sie versuchen, Entitäten wie Organisationen, Umgebungen, benutzerdefinierte Rollen oder Berechtigungen zu erstellen, wird möglicherweise die Fehlermeldung "message": "[LDAP: error code 80 - Other]" angezeigt.
  • Alle DNs, die länger als 241 Byte sind, sind betroffen. Solche DNs verhindern ein erfolgreiches Upgrade der Apigee OpenLDAP-Software. Sie müssen Gegenmaßnahmen für solche Elemente ergreifen, bevor Sie mit dem Upgrade fortfahren können.

Im LDAP von Apigee hängen lange DNs in der Regel mit Berechtigungen zusammen, da sie durch Verketten mehrerer Entitäten erstellt werden. Solche Berechtigungseinträge sind besonders anfällig für Probleme bei der Aktualisierung.

Beispiel: 

dn: cn=@@@environments@@@*@@@applications@@@*@@@revisions@@@*@@@debugsessions,ou=resources,cn=businessuser,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com

Normalerweise haben Organisations-, Umgebungs- und Rollennamen eine Länge, sodass RDNs in LDAP kleiner als 241 Byte sind.

Problembehebung

Vor dem Upgrade auf Version 4.53.01:

Mit den folgenden Schritten können Sie prüfen, ob in Ihrem bestehenden LDAP 2.4-Cluster lange RDNs vorhanden sind.

1. LDAP-Daten extrahieren

Verwenden Sie den Befehl „ldapsearch“, um den definierten Namen (dn) zu finden, und leiten Sie die Ausgabe an eine Datei weiter: 

ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w LDAP_PASSWORD dn > /tmp/DN.ldif

Prüfen Sie, ob die Datei „DN.ldif“ oben LDAP-Einträge enthält.

#2 – Lange RDNs identifizieren

Suchen Sie in der Datei „DN.ldif“ oben nach den RDNs, die 241 Byte/Zeichen überschreiten:

cat /tmp/DN.ldif |  grep '^dn:' | gawk -F',|dn: ' '{ rdn = $2; char_count = length(rdn); cmd = "echo -n \"" rdn "\" | wc -c"; cmd | getline byte_count; close(cmd); if (char_count > 241 || byte_count > 241) { print rdn, "(chars: " char_count ") (bytes: " byte_count ")"; }}'
o=VeryLongOrgNameWithMoreThan241Chars.... (chars: 245) (bytes: 245)
cn=VeryLongCustomRoleNameWithMoreThan241Chars.... (chars: 258) (bytes: 258)

Wenn der obige Befehl keine Ausgabe erzeugt, überschreiten keine RDNs in der vorhandenen LDAP-Einrichtung 241 Byte/Zeichen. Sie können das Upgrade wie gewohnt durchführen.

Wenn der obige Befehl eine Ausgabe generiert, weist dies auf das Vorhandensein von RDNs hin, die 241 Byte/Zeichen überschreiten. Führen Sie für solche Elemente die in Schritt 3 beschriebenen Maßnahmen zur Risikominderung aus, bevor Sie mit dem Upgrade auf Edge for Private Cloud 4.53.01 fortfahren.

#3 – Lange RDNs verarbeiten

Wenn in Schritt 2 eine Ausgabe erfolgt, bedeutet dies, dass RDNs mit mehr als 241 Byte/Zeichen vorhanden sind. Führen Sie die folgenden Schritte zur Fehlerbehebung aus:

Prüfen Sie die LDAP-Einträge, die 241 Byte überschreiten.

  • Wenn es sich um den Namen einer benutzerdefinierten Rolle, einer App, eines API-Produkts oder anderer Entitäten handelt, die hauptsächlich für den langen RDN verantwortlich sind, migrieren Sie zu einer alternativen Entität mit einem kürzeren Namen.
  • Wenn der Organisationsname oder der Umgebungsname der Hauptgrund für den langen RDN ist, müssen Sie zu einer anderen Organisation oder Umgebung mit einem kürzeren Namen migrieren.

Wiederholen Sie die obigen Schritte, bis Ihr LDAP keine RDNs mehr enthält, die länger als 241 Byte sind. Sobald Sie diesen Status erreicht haben, fahren Sie wie gewohnt mit dem Upgrade der privaten Cloud-Version fort.

Änderungen am Kryptografieanbieter

Kontext

Diese Änderung wurde aus Edge for Private Cloud 4.53.00 übernommen. In Edge for Private Cloud 4.53.00 wurde der interne Kryptografieanbieter von Bouncy Castle (BC) auf Bouncy Castle FIPS (BCFIPS) aktualisiert, um FIPS-Unterstützung zu ermöglichen.

Änderungen

Wenn JavaCallout-Richtlinien auf dem ursprünglichen BC-Provider basieren, insbesondere bei Verwendung von Sicherheitsfunktionen, die im BCFIPS-Provider gehärtet wurden (z. B. Verwendung eines gemeinsamen Schlüsselpaars für Verschlüsselung und Signierung), müssen diese JavaCallout-Richtlinien modernisiert werden. JavaCallout-Richtlinien, die versuchen, den Bouncy Castle-Kryptografieanbieter mit dem Namen BC zu laden, können fehlschlagen, da sich der Standardanbieter geändert hat. Solche Richtlinien, die den BC-Anbieter verwenden, können später fehlschlagen. Benutzerdefinierte Implementierungen, die auf dem alten BC-Anbieter basieren, sind nicht mehr zugänglich und müssen überprüft und neu implementiert werden.

Problembehebung

Die empfohlene Problemumgehung besteht darin, den BCFIPS-Anbieter zu verwenden. Benutzerdefinierte JavaCallout-Implementierungen, die auf dem alten Provider basierten, müssen überprüft und mit dem Bouncy Castle FIPS-Provider neu implementiert werden. Auf diesen kann mit dem String „BCFIPS“ zugegriffen werden.

Automatisiertes Tool zur Änderungserkennung

Ein Tool zur Änderungserkennung ist in Planung und wird demnächst veröffentlicht. Mit diesem Tool können API-Proxys, freigegebene Abläufe, Ressourcen und LDAP-RDNs gescannt und identifiziert werden, die möglicherweise von den in diesem Artikel beschriebenen Änderungen betroffen sind. Dieses Tool soll dabei helfen, verschiedene Entitäten zu identifizieren, die während oder nach dem Upgrade auf Edge for Private Cloud 4.53.01 anfällig für Fehler sind.