We gaan onze API nog veiliger maken door enkel user based authentication toe te passen.
Wat is “user based” authentication? Waarom is user based authenticatie beter dan application based authenticatie? En niet onbelangrijk, hoe gaan we gebruikersgebaseerde authenticatie implementeren binnen Azure API Management en applicatiegebaseerde authenticatie tegengaan?
In deze blog ga ik twee heerlijke persoonlijkheden gebruiken om te laten zien hoe belangrijk persoonlijke identiteiten zijn. We beginnen en eindigen met onze hoofdrolspeler Dexter Morgan…
Het einde van Dexter Morgan (spoiler alert)
Ja, het einde is aangebroken voor Dexter. Net zoals in het laatste seizoen is het niet langer mogelijk om zijn acties te verhullen. In het slotseizoen van de serie interpreteert zijn zoon dit iets letterlijker dan mijn implementatie. Ik heb namelijk niet de bedoeling om iemand van het leven te beroven.
Nee, we gaan de API van het Miami Metro Police Department veiliger maken door de API alleen toegankelijk te maken voor persoonlijke identiteiten, oftewel user-based. Iedereen die gebruikmaakt van de applicatie (en dus de API) moet zijn persoonlijke identiteit gebruiken.
Alle API-requests dan herleid worden naar een individuele identiteit in plaats van een applicatie die door meerdere personen gebruikt kan worden.
Dexter, als kwaadwillende gebruiker van de applicatie, kan zich momenteel verdedigen door te zeggen: “Dat was ik niet, er zijn meer dan 100 collega’s met toegang tot de applicatie.” Helaas is er geen overtuigend bewijs voor schuld en veroordeling.
Grootste fout van Jimmy McGill?
Mijn tweede favoriet is een criminele advocaat: Saul Goodman. Ik kan me niet voorstellen dat je Saul Goodman niet kent, maar hier is een link naar zijn biografie.
Ik heb ChatGPT gevraagd wat zijn grootste fout is…
Saul Goodman's biggest mistake regarding his identity in Breaking Bad was ultimately trusting Walter White and becoming entangled in his illegal activities.
Saul Goodman heeft in vertrouwen aan Walter White zijn ware identiteit onthuld, waardoor criminele handelingen ook het leven van Jimmy McGill beïnvloedden.
Voor onze API is het belangrijk dat er persoonlijke identiteiten worden gebruikt, zodat dubieuze acties niet kunnen worden uitgevoerd onder een dergelijk pseudoniem. Denk hierbij aan een alias van een applicatie die geen onderscheid maakt tussen het gebruik van één of meerdere personen.
User based authentication
Laten we beginnen met de vraag: wat is gebruikersgebaseerde authenticatie? Ik vraag het aan mijn eenzijdige maar grote vriend, ChatGPT.
User-based authentication, also known as user authentication, is the process of confirming the identity of an individual user to ensure that they are authorized to access a system or application. It involves verifying the user's credentials, such as username and password, before granting access to restricted resources. This method is widely used in various systems and platforms to protect sensitive information and ensure that only valid users can access the authorized resources.
IIk weet niet hoe het met jullie zit, maar ik kan erg goed leven met het antwoord. Op naar de implementatie, waar ik geen gebruik zal maken van ChatGPT.
Implementatie user based authentication binnen API Management
Nu gaan we daadwerkelijk user based authentication implementeren en ervoor zorgen dat de API niet kan worden gebruikt op basis van de applicatie-identiteit.
API Management policy
Voordat je verder leest, is het goed om even mijn vorige blog erbij te pakken. Hierin zijn namelijk alle randvoorwaarden besproken, en we gaan de “validate-azure-ad-token” policy hergebruiken. Deze policy kunnen we één op één overnemen.
Voor de volledigheid geef ik hierbij de “validate-azure-ad-token” policy:
<policies>
<inbound>
<base />
<validate-azure-ad-token tenant-id="{{aad-tenant}}" header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<client-application-ids>
<application-id>{{backend-app-client-id}}</application-id>
<!-- If there are multiple client application IDs, then add additional application-id elements -->
</client-application-ids>
</validate-azure-ad-token>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>We gaan deze app-registratie hergebruiken en verder optimaliseren.
Azure AD configuratie van de App Registration
Na een tweetal van mijn helden en een bekende Azure API Management-policy kunnen we nu doorgaan met nieuwe inhoud. Wat moeten we aanpassen aan de huidige App Registration?
We gaan in vier stappen ervoor zorgen dat enkel persoonlijke identiteiten de API kunnen gebruiken.
Stap 1. Blokkeren van het service account (App Registration)
Allereerst zorgen we ervoor dat de API niet kan worden aangeroepen op basis van de applicatie-identiteit. Dit is zeer belangrijk, anders kunnen kwaadwillenden toch nog gebruikmaken van het “serviceaccount“. Dit doen we heel eenvoudig door de instelling binnen de Enterprise Application “MMPD-api” aan te passen: Properties -> Assignment required? Yes.
Deze instelling zorgt ervoor dat er een toewijzing nodig is en is alleen van toepassing op groepen en gebruikers, niet op losse App-registraties (client-id).
Stap 2. Gebruikers toekennen aan de Enterprise Application
Nu we de “App Registration” niet langer kunnen gebruiken, moeten we persoonlijke identiteiten toekennen aan de Enterprise Application. Daarvoor zijn twee acties nodig:
- Enabled for users to sign-in? Deze instelling moet worden ingesteld op “Ja”. De melding “Gebruikers hebben geen toegang tot deze applicatie” in de bovenstaande schermafbeelding zal dan verdwijnen.
- Klik op “Gebruikers en groepen” binnen het menu aan de linkerkant van de Enterprise Application. Hier kun je vervolgens gebruikers/groepen toevoegen die gemachtigd zijn om de Enterprise Application te gebruiken.
Testen
Om te kunnen testen, dien je met een persoonlijk account (identiteit) een bearer-token op te vragen bij je AAD. Hiervoor heb ik een MSAL-applicatie gebruikt.
Microsoft heeft talloze voorbeelden hiervan op Microsoft Learn.
Je kunt natuurlijk ook “gewoon” Postman gebruiken. Zorg er dan wel voor dat je een geldig persoonlijk bearer-token hebt en probeer vervolgens je API te gebruiken. Hieronder vind je een voorbeeld van mijn Postman-resultaat met de Dexter-crimecases…
Hiermee komt er een einde aan de avonturen van Dexter (zowel letterlijk als figuurlijk).
