Voorbeeld klantcase
Een van onze klanten had een aangepaste autorisatieservice voor het autoriseren van bepaalde Paths. Voor authenticatie gebruikten ze Okta. Zij wilden een autorisatiebeleid dat op een globaal niveau kan worden toegepast, zodat het niet nodig is dat elke API zijn eigen aangepaste autorisatieservice aanroept vanuit de bemiddelingslogica. Ze hadden veel API’s en een bemiddelingsbeleid voor elke API was geen optie.
WSO2 Standaard mediation gateway-stroom kan worden uitgebreid met verschillende soorten extensies. De drie belangrijkste extensies worden hieronder vermeld.
[1] Aangepaste sequenties [2] Aangepaste API-handlers [3] Aangepaste Synapse handlersAangepaste volgorde
Synapse sequenties kunnen worden ingeschakeld in de request in flow of de response out flow. Deze benadering vereist dat voor elke API bemiddelingsreeksen worden gemaakt. Telkens wanneer een nieuwe API wordt gemaakt, kan een aangepaste sequentie worden toegevoegd voor autorisatie.
Aangepaste API-handler
In deze benadering wordt een aangepaste handler (uitbreiding van de klasse org.apache.synapse.rest.AbstractHandler) geschreven en wordt een handtekening toegevoegd aan elke API. Als er voor alle API’s een wijziging moet worden aangebracht, wordt Velocity_template.xml bewerkt. Probleem met deze aanpak is dat alle bestaande API’s opnieuw moeten worden ingezet. Er zijn ook gevallen waarin er onbeveiligde API’s zijn en deze wijziging heeft ook gevolgen voor die API’s. Daarnaast zal deze wijziging de upgrades bemoeilijken omdat wijzigingen in het velocity-bestand handmatig zullen moeten worden samengevoegd. Problemen met deze aanpak zijn goed gedocumenteerd in de wso2-documentatie (https://docs.wso2.com/display/AM210/Writing+Custom+Handlers)
Aangepaste synapse handlers
Dit is een globale extensie-handler die voor elke API-aanroep wordt uitgevoerd. Aangepaste Java-code implementeert de org.apache.synapse.SynapseHandler-interface en kan de voorwaarden specificeren waaronder de ingesloten logica moet worden uitgevoerd.
Benadering
Wij besloten om voor ons project de aangepaste synapse handler aanpak te gebruiken, omdat het niet nodig zou zijn om handmatig een Handler handtekening toe te voegen in elke API, in tegenstelling tot het gebruik van een Custom API Handler, zoals hierboven vermeld
Stappen op hoog niveau
1) Schrijf een aangepaste Java-code die de interface en methoden org.apache.synapse.SynapseHandler implementeert ( handleRequestInFlow(MessageContext messageContext) en handleRequestOutFlow(MessageContext messageContext) ). handleRequestInFlow(MessageContext messageContext) is de methode die wordt uitgevoerd net nadat het verzoek de synaps-engine (APIM) raakt en de logica bevat om te beslissen of het verzoek naar de backend moet worden verzonden of niet.
2) Maak een JAR en implementeer deze in de directory ${wso2_APIM}/repository/components/lib. Dit kan worden geautomatiseerd met behulp van Jenkins-pijplijnen.
Uitvoeringsfasen
1) Breid de globale handler uit om verbinding te maken met de autorisatieservice
2) Overschrijf de handleRequestInFlow(MessageContext messageContext) om de Custom Authorization-service aan te roepen en de isAuthorized-vlag in te stellen op basis van het antwoord.
3) Geef deze vlag (is geautoriseerd) door aan de bemiddelingsvolgorde (indien aanwezig). Als er geen bemiddelingsreeks is, houdt u deze gewoon leeg
4) Overschrijf de handleRequestOutFlow(MessageContext messageContext) om de vlag Status te controleren
Conclusie
Door de synapse handler te negeren, kunnen aangepaste validaties worden geplaatst voordat het verzoek het eindpunt bereikt. Aangezien dit een algemeen beleid is, hoeft elke API niet te worden gewijzigd/opnieuw geĂŻmplementeerd.
