Beispiel für einen Kundenfall
Einer unserer Kunden hatte einen eigenen Autorisierungsdienst für die Freigabe bestimmter Pfade. Zur Authentifizierung nutzten sie Okta. Sie benötigten eine Autorisierungsrichtlinie, die global angewendet werden konnte, damit nicht jede API ihren eigenen individuellen Autorisierungsdienst über die Vermittlungslogik aufrufen musste. Sie hatten viele APIs und es war keine Option, Übermittlungrichtlinien für jede API zu haben.
WSO2 Default Mediation Gateway Flow kann mit verschiedenen Arten von Zusätzen erweitert werden. Die drei Haupterweiterungen sind nachstehend aufgeführt.
[1] Benutzerdefinierte Abläufe [2] Benutzerdefinierte API-Handler [3] Benutzerdefinierte Synapse-HandlerBenutzerdefinierte Abläufe
Synapsenfolgen können in den Informationsfluss der Anfrage oder in den Informationsfluss der Antwort eingebunden werden. Bei diesem Ansatz müssen für jede API Vermittlungssequenzen erstellt werden. Immer wenn eine neue API erstellt wird, kann eine benutzerdefinierte Sequenz für die Autorisierung hinzugefügt werden.
Benutzerdefinierter API-Handler
Bei diesem Ansatz wird ein benutzerdefinierter Handler (der die Klasse org.apache.synapse.rest.AbstractHandler erweitert) erstellt und eine Signatur zu jeder API hinzugefügt. Wenn Änderungen für alle APIs vorgenommen werden müssen, wird velocity_template.xml bearbeitet. Das Problem bei diesem Ansatz ist, dass alle bestehenden APIs neu implementiert werden müssen. Außerdem gibt es Fälle, in denen ungesicherte APIs vorhanden sind. Diese Änderung wirkt sich auch auf sie aus. Abgesehen davon erschwert diese Änderung die Upgrades, da die Veränderungen an der Velocity-Datei manuell zusammengeführt werden müssen. Die Probleme mit diesem Ansatz sind in der wso2-Dokumentation gut beschrieben (https://docs.wso2.com/display/AM210/Writing+Custom+Handlers)
Benutzerdefinierte Synapse-Handler
Dieser globale Erweiterungshandler wird bei jedem Api-Zugriff ausgeführt. Ein kundenspezifischer Java-Code initialisiert die Schnittstelle org.apache.synapse.SynapseHandler und kann die Bedingungen angeben, unter denen die darin enthaltene Funktion ausgeführt werden soll.
Ansatz
Wir haben uns bei unserem Projekt für die kundenspezifische Synapse-Handler-Methode entschieden, da es dadurch, wie oben beschrieben, im Gegensatz zum kundenspezifischen API-Handler nicht notwendig ist, manuell eine Handler-Signatur in jede Api einzufügen.
Verfahren auf oberster Stufe
1) Schreiben Sie einen benutzerdefinierten Java-Code, der die org.apache.synapse.SynapseHandler- Schnittstelle und -Methoden (handleRequestInFlow(MessageContext messageContext)sowie handleRequestOutFlow(MessageContextmessageContext)) initialisiert.
handleRequestInFlow(MessageContext messageContext) ist die Routine, die ausgeführt wird, wenn die Anfrage die Synapse-Engine (APIM) erreicht hat, welche die Regel enthält, die entscheidet, ob die Anfrage an das Backend gesendet werden muss oder nicht.
2) Erstellen Sie eine JAR-Datei und stellen Sie sie ins Verzeichnis ${wso2_APIM}/repository/components/lib. Dies lässt sich mit Jenkins-Pipelines automatisieren.
Implementierungsschritte
1) Erweitern Sie den globalen Handler, der die Verbindung zum Autorisierungsdienst herstellen soll.
2) Überschreiben Sie handleRequestInFlow(MessageContext messageContext), um den Custom Authorization Service aufzurufen und nach dessen Antwort isAuthorized Flag zu bestimmen.
3) Übergeben Sie dieses Merkmal (isAuthorized) an die Mediation Sequence (falls vorhanden). Wenn es keine Mediationssequenz gibt, lassen Sie das Feld einfach leer.
4) Überschreiben Sie die handleRequestOutFlow(MessageContext messageContext) um den Flag Status zu prüfenxt messageContext) om de vlag Status te controleren
Conclusie
Durch Überschreiben des Synapse-Handlers können benutzerdefinierte Validierungen durchgeführt werden, bevor die Anfrage den Zielpunkt erreicht. Da es sich um eine globale Strategie handelt, muss nicht jede API verändert/neu initialisiert werden.
