De WSO2 API-manager kan verwarrend zijn. Het is werkelijk een groot product waarin functies van een scala aan andere producten hergebruikt worden, zoals de Enterprise Service Bus, de Complex Event Processor, de Message Broker, de Enterprise Store en de Data Analytics Server (wat op zich al een collectie aan producten is). Het aanbod is uiterst breed in zaken zoals lifecycle management, beleidsbeheer, developer engagement en beleidshandhaving om er maar een paar te noemen. En dat allemaal binnen één enkel product. Het is dan ook allerminst verwonderlijk dat architecten en administrators er een zware dobber aan hebben om dat allemaal onder de knie te krijgen. In deze post zullen proberen er wat meer duiding aan te geven.
De basis van beleid
Laten we eerst eens kijken naar het uiteindelijke doel waarvoor beleidshandhaving nodig is. Het maakt niet uit of dit beleid gaat over hoe er toegang verkregen wordt tot je gegevens, of dat het gaat over welke API’s er aangeroepen kunnen worden, of over bijvoorbeeld authenticatie, zonder de juiste handhaving is het een fundamenteel gebrekkig beleid. Als je het voor jezelf gemakkelijk wilt maken, creëer je slechts één toegangspunt waar je al je beleid verplicht kunt maken. Dit is jouw Policy Enforcement Point, ofwel PEP. Meer toegangswegen is uiteraard mogelijk, maar dan moet je wel onthouden dat het geen zin heeft de voordeur zwaar te beveiligen als je achterdeur wagenwijd openstaat. Je kunt beleidshandhaving zien als de barrière bij de grenscontrole.
Waarom en waarvoor heb je API Management nodig?
Nu downloadenOké, nu heb je het voor elkaar dat al je beleid van kracht is. Hoe kun je er dan voor zorgen dat iedereen zich er ook aan houdt? Nogmaals, aan de grens moet je een legaal document tonen om binnen te komen. Het is waarschijnlijk niet zo moeilijk om vast te stellen of iemand een document heeft. Maar is het legaal of vervalst? Is het nog steeds geldig of is het verlopen of is de geldigheid ingetrokken? Is de persoon werkelijk de eigenaar van dit document? Staat hij op een verdachtenlijst? Er kunnen allerlei complicaties optreden in het besluit of jouw beleid, het bezit van een legaal document, overtreden wordt. Dat is waar er sprake is van een Policy Decision Point (PDP).
Besluiten over het beleid moeten uiteraard zo eerlijk en objectief mogelijk genomen worden. Je zou niet willen dat het douanepersoneel er zijn eigen regels op na gaat houden. Om beleid dus ondubbelzinnig op te stellen, heb je een Policy Administration Point (PAP) nodig. Dit is de bron waar jouw PDP op zal vertrouwen. Let erop dat beleidsadministratie en beleidshandhaving verschillende vakken zijn. Het zou maanden kunnen duren om een nieuw beleid of beleidswijziging op te stellen en te testen. En normaliter worden er eens per week of per maand beleidswijzigingen doorgevoerd. Beleidshandhaving gaat daarentegen dag en nacht door, waarbij besluiten snel genomen moeten worden en wachttijden vermeden.
Om de werelden van beleidsuitvoering en beleidsontwikkeling bij elkaar te brengen, zul je waarschijnlijk bewustzijn over de situatie moeten creëren. Hoe goed werkt het beleid voor je? Heb je hulp nodig bij het fine-tunen ervan? Of misschien zou je de impact van geplande beleidswijzigingen willen simuleren en beoordelen? Daarvoor, en voor heel veel andere zaken, heb je informatie nodig van de afdeling beleidsuitvoering. Ik stel je voor aan jouw Policy Information Point (PIP). Dat is waar je alle genomen besluiten kunt monitoren en kunt beoordelen of je beleid daadwerkelijk zo werkt als je gedacht had. Dat maakt de beleidscirkel rond.
API Beleid
Hoe brengen we dit samen in de WSO2 API-manager? Nou, het zal je niet verbazen dat dat de API Gateway is, jouw PEP. Dat is het toegangspunt dat toestemming om binnen te komen geeft of weigert. Deze Gateway heeft een paar assistenten om te helpen bij de besluitvorming wat betreft beleidshandhaving: Dat zijn de Key Manager, die gevraagd wordt om besluiten te nemen over beleid met betrekking tot toegangscontrole, en de Traffic Manager, die beleid waar dingen op vastlopen operationeel maakt. Dat zijn je PDP’s. De manier waarop WSO2 de interfaces voor deze componenten heeft geïmplementeerd verschilt een beetje. De Key Manager interface is een real-time interface, met een optionele cache om de gehele prestatie te verbeteren. De Traffic Manager is daarentegen een near-real time interface. Het wordt continu gevoed met events, monitort API-traffic en evalueert of beleid overtreden wordt, waarbij complexe aanvragen van grote sets aan events op kunnen treden. Als er een overtreding optreedt, houdt dat in dat de Gateway zijn operationele set aan beleidsregels zo snel mogelijk moet bijwerken. Dit zijn de beleidsregels die het real-time evalueert, zoals een zwarte lijst met IP-adressen. De Traffic Manager stuurt dus een bericht naar de Gateway om precies dat te doen. Je kunt het zien alsof de Traffic Manager real-time een besluit delegeert aan de Gateway voor een simpele set beleidsregels, zoals dat de politie een lijst nummers van gestolen paspoorten deelt met de douane.
Het API Publishing and Management Portal is natuurlijk de PAP. Hier bepaal je uiteindelijk het API-beleid. Daarnaast is het API Developer Portal, waar een ontwikkelaar de toegestane toepassingen definieert en zijn abonnementen beheert, tot op zekere hoogte ook een PAP. Afhankelijk van de workflows die je definieert, kunnen er verschillende rollen betrokken zijn bij het bepalen van welke registraties van ontwikkelaars en welke API-abonnementen je wilt accepteren. Dat maakt je workflow praktisch gezien ook een PDP.
API Manager Analytics dient tot slot als PIP in de WSO2 API-manager. Hier kun je naar hartenlust alle rapporten die de API-manager standaard genereert bekijken en analyseren. En als je nog meer zou willen, dan is er altijd de optie om te upgraden naar een volledige WSO2 Data Analytics Server.
Om te onthouden
Kennis over welke functies de verschillende componenten van de WSO2 API-Manager vervullen kan helpen bij het bepalen van je deploymentstrategie. Je zou ervoor kunnen kiezen om ze allemaal bij elkaar in je ontwikkelingsomgeving te hebben, maar je zou ook kunnen gaan voor een productieomgeving waarbij design-time en run-time componenten gescheiden worden. Het is ook mogelijk om jouw Gateway uit te rollen in een netwerkomgeving afgescheiden van je Key Manager en Traffic Manager. In die setup kan de Gateway draaien zonder verbinding met je gedeelde databases. In andere woorden: zo kun je jouw gegevens veilig achter je eigen firewall houden. Uiteraard zul je de juiste instellingen voor je proxy’s en firewalls moeten hebben om te allen tijde de juiste verbindingsmogelijkheden tussen de componenten te verzekeren.
Al met al zijn er veel opties om te overwegen en zal het waarschijnlijk de nodige bedenktijd kosten de beste manier te vinden om de componenten die jij voor jouw API-manager kiest in te bouwen in een volledige omgeving, waarbij je je ook nog dient te houden aan je eigen netwerk- en veiligheidsprincipes. Dan hebben we het nog niet eens over een multiple gateway scenario (als er verschillende API Gateways in verschillende datacentra of netwerkzones draaien) om bijvoorbeeld intern en extern verkeer te scheiden. De mogelijkheden zijn letterlijk oneindig. Jij hebt het geluk dat Yenlo er is om de opties die jij wenst mee te bespreken en je kan helpen bij het kiezen van het beste scenario. Het beste van alles is dat het waarschijnlijk ook de levensvatbaarheid van het idee kan bewijzen (wat een maar weinig geziene praktijk is). We hebben het uiteindelijk al eens eerder gedaan. We runnen graag een API-architecture workshop om je te helpen jouw uitdagingen te overwinnen of helpen je op een andere manier die bij jou past.
Wil je weten welk API-product past bij jouw zakelijke eisen? Bekijk dan de mogelijkheden in het white paper hieronder, waar we verschillende API-aanbieders en de functies van hun producten met elkaar vergelijken.