Azure API Management authenticatie

[Armageddon_2k]

Ik heb een vraag over het beheren van een API middels Azure API management.

Doel/context
We hebben momenteel een web app en API draaien welke de authenticatie zelf voor zijn rekening neemt. Uiteindelijke doel is om de API als odata bron te gebruiken om Excel te voeden. Hierbij willen we gebruik maken van inloggen met 'organizational account'. Momenteel gebruiken we nog een IExplorer instantie vanuit VBA om een JWT token te krijgen en deze te gebruiken voor authenticatie. Dit laatste werkt prima, maar wegens overduidelijke reden willen we af van VBA en IExplorer.

Wat ik al gevonden of geprobeerd heb
We hebben verschillende pogingen gedaan om de API rechtstreeks via 'organizational account' vanuit Excel te benaderen maar vallen van de ene in de andere rabbithole.
Veel online verhaaltjes van learn.microsoft gevolgd, maar deze dekken steeds maar delen van het toaal.

We zien ook dat Azure API management hierbij zou kunnen helpen, maar daarbij heb ik nog een meer principiele vraag, vandaar deze post.



Als ik naar bovenstaande kijk en alle voorbeelden hierbij, dan krijg ik het prima werkend. We hebben een API en we hebben API management waarop ik rechten kan inrichten.
Optie 1
Ik kan op de backend API authenticatie aanzetten, maar dan begint API mangement te miepen en krijg ik un-authorized meldingen.
Optie 2
De backend API de authenticatie uit te zetten dan kan API management er wel bij. Alleen hoe scherm ik dan de backend API af? momenteel is deze nog volledig exposed aan internet. En dan schiet het zijn doel natuurlijk een beetje voorbij.

[P-Storm]

Ik denk dat je het los moet koppelen in de verschillende stappen.
1. Heb je de 'Client App' in beheer en hoe haal je authenticatie token hiervan op?
2. Welke Azure API Management gebruik je? Waarom gebruik je het?
3. Hoe zit het met de target applicatie? Je schrijft een backend API, maar schrijft deze in de Excel? Heb je deze in beheer? Hoe zit het met authenticatie/authorisatie hier?

Basically mis ik hier informatie over hoe de authorisatie geregeld wordt, dit kan op veel verschillende manieren gedaan worden. JWT zegt alleen de payload, maar hoe zit het met jou Identity Provider? Voor Auth0 is het weer heel anders dan Microsoft Entra ID.

Zonder deze informatie zou mijn plan zoiets zijn:
1. Backend met mock data voeden, en die wegschrijven in een excel
2. Client app connectie maken met de backend Api
3. Authorisatie op backend zetten. Vaak heeft een taal (zoals dotnet) een framework hiervoor, die je aan een identity server kan hangen. Dit is inclusief waar de applicatie de OAuth settings plaats moeten vinden. In combinatie met stap 4 dus.
4. Implementeren dat vanuit de Client App de JWT opgehaald kan worden. Welke flow gaat hiervoor geschikt zijn?
5. Hoe ga je met het renewen van een JWT om? Sliding update de token? Forceer de gebruiker binnen lifetime dingen te doen, anders een redirect en opnieuw login?

En de andere vraag is, waarom heb je een Azure API Managment nodig?

[frAmEd]

Optie 2
De backend API de authenticatie uit te zetten dan kan API management er wel bij. Alleen hoe scherm ik dan de backend API af? momenteel is deze nog volledig exposed aan internet. En dan schiet het zijn doel natuurlijk een beetje voorbij.

Dit kun je doen door in de backend API netwerkrestricties toe te passen en alleen het IP van API Management te whitelisten. Dit kun je softwarematig in de backend API doen (minst goede optie) of je gebruikt een VNET met NSG (Network Security Group) of een Firewall.

Dan zou de flow als volgt kunnen zijn:
1. Client applicatie krijgt via een subscriptie op de API in API Management een token voor APIM
2. Via APIM spreek je backend aan zonder extra authenticatie
3. Al het verkeer van internet wat buiten APIM omgaat wordt geblokkeerd door de netwerkrestricties in/op de backend API

[Armageddon_2k]

frAmEd schreef op dinsdag 24 september 2024 @ 09:12:
[...]


Dit kun je doen door in de backend API netwerkrestricties toe te passen en alleen het IP van API Management te whitelisten. Dit kun je softwarematig in de backend API doen (minst goede optie) of je gebruikt een VNET met NSG (Network Security Group) of een Firewall.

Dan zou de flow als volgt kunnen zijn:
1. Client applicatie krijgt via een subscriptie op de API in API Management een token voor APIM
2. Via APIM spreek je backend aan zonder extra authenticatie
3. Al het verkeer van internet wat buiten APIM omgaat wordt geblokkeerd door de netwerkrestricties in/op de backend API

Ik was er al een beetje bang voor dat het deze kant op zou gaan.
Soms snap ik het beleid van Microsoft niet helemaal, voorbeeld:
Het benaderen van de Azure SQL database is dan wel weer binnen azure helemaal af te dichten zonder gebruik van additionele rules/vnet/etc. Daarbij kan je public netwerk uitzetten, en de webapp haalt zn data op middels managed identity. Ik had de hoop dat dat ook mogelijk was met APIM en dat ik daarbij gewoon iets over het hoofd had gezien. Maar helaas.

[frAmEd]

Ik was er al een beetje bang voor dat het deze kant op zou gaan.
Soms snap ik het beleid van Microsoft niet helemaal, voorbeeld:
Het benaderen van de Azure SQL database is dan wel weer binnen azure helemaal af te dichten zonder gebruik van additionele rules/vnet/etc. Daarbij kan je public netwerk uitzetten, en de webapp haalt zn data op middels managed identity. Ik had de hoop dat dat ook mogelijk was met APIM en dat ik daarbij gewoon iets over het hoofd had gezien. Maar helaas.

Je kan ook de andere kant opgaan met auth token transformaties. Je kan dan via OAuth communiceren met APIM en APIM kan geldige tokens via transformation policies vertalen naar tokens/keys die de backend accepteert. Zo kan alleen iemand die via APIM communiceert een geldig token voor de backend krijgen en heb je de netwerkrestricties niet per se nodig.

[Falcon]

Je mist denk ik in jouw situatie nog een AzureB2C instantie:



Waar Azure Functions dan jouw BE api is en de SPA jouw Client App.

[ Voor 9% gewijzigd door Falcon op 24-09-2024 11:02 ]

[SiErRa]

Armageddon_2k schreef op dinsdag 24 september 2024 @ 09:57:
[...]


Ik was er al een beetje bang voor dat het deze kant op zou gaan.
Soms snap ik het beleid van Microsoft niet helemaal, voorbeeld:
Het benaderen van de Azure SQL database is dan wel weer binnen azure helemaal af te dichten zonder gebruik van additionele rules/vnet/etc. Daarbij kan je public netwerk uitzetten, en de webapp haalt zn data op middels managed identity. Ik had de hoop dat dat ook mogelijk was met APIM en dat ik daarbij gewoon iets over het hoofd had gezien. Maar helaas.

Je kan APIM onder zijn managed identity ook een JWT laten ophalen bij Entra, en daarmee naar je backend gaan. Dit gaat met AppRegistrations in Entra. Dan heb je een model wat op dat van Azure SQL lijkt.