OAuth implementatie bij Miami Metro Police Department

We gaan Miami Metro Police Department (MMPD) helpen met de implementatie van moderne authenticatie. Vanaf vandaag wordt het gebruik van een API herleid naar de applicatie die de API consumeert dus wees gewaarschuwd Dexter Morgan!

Wat zijn de drie prerequisites tijdens de implementatie? Hoe ziet onze API policy eruit? En nog veel belangrijker… Hoe kan jij, na het lezen van deze blog post, direct aan de slag?

"Ik steel van rijken en verdeel het onder de armen".
Robin Hood

Hierbij alvast de bronvermelding waar ik een deel van de content gestolen heb: https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad

Wat hebben we nodig?

MMPD heeft inmiddels de eerste stappen gezet richting Azure:

• De Azure AD tentant is geïmplementeerd;
• API Management is succesvol uitgerold zodat alle API’s centraal gepubliceerd kunnen worden;
• De eerste API’s zijn al te consumeren met tussenkomst van API Management.

Ik ga je met deze blog dus niet helpen met het opzetten van de bovenstaande randvoorwaarden.

Waar ga ik dan wel bij helpen?

Het leukste gedeelte natuurlijk: we gaan eerst Dexter zijn applicatie registreren binnen de Azure tenant van MMPD en een policy configureren die inkomende bearer tokens gaat beoordelen. Alleen API calls met een geldig token (authorization header) kunnen geconsumeerd worden.

API beschermen met Azure AD OAuth authenticatie

Allereerst gaan we een app registration aanmaken voor onze API. Hopelijk moet je, net als ik, eerst je rechten ophogen door middel van Privileged Identity Management (PIM) zodat we een app registration kunnen aanmaken binnen Azure AD.

Met je Global Administrator role kan je nu de API registreren. Zie de “Register an application in Azure AD to represent the API” stap binnen de Microsoft documentatie.

Zie hieronder het resultaat van de eerste stap “Register an application in Azure AD to represent the API” waarin we een scope hebben aangemaakt om bewijslast van alle cases op te vragen.

Op naar de volgende stap waar we een policy gaan configureren en toepassen.

Policy configureren en toepassen

Binnen de tweede stap van de documentatie “Configure a JWT validation policy to pre-authorize requests” maakt Microsoft gebruik van een openid-configuratie. In mijn voorbeeld gaan we gebruik maken van de “validate-azure-ad-token” policy. Deze policy is speciaal ontwikkeld voor de Azure AD service en valideert de aangeboden JSON web token.

Als je deze blog als leidraad gebruikt voor je configuratie is de xml policy anders dan in de Microsoft documentatie. Er is geen goed of fout dus bepaal gerust je eigen voorkeur.

<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>

Het script hierboven bevat een tweetal named values waar de secrets zijn opgeslagen:

• aad-tenant;
• backend-app-client-id.

BELANGRIJK: zorg dat je secrets nooit zichtbaar zijn in de policy! 

Dexter en Postman

Onze lieve Dexter maakt gebruik van Postman om zijn API’s te testen dus laten we even meekijken met Dexter. We zien zo meteen twee API’s calls in actie die nodig zijn voor het opvragen van moordzaken. Hij moet namelijk eerst een bearer token ophalen alvorens hij de moordzaken kan inzien.

Stap 1: bearer token ophalen bij Azure AD

We hebben inmiddels Dexter zijn API beveiligd door middel van Azure AD. Als Dexter daadwerkelijk data wilt ophalen moet er eerst authenticatie plaats vinden. Laten we eerst kijken hoe Dexter zich kan authentiseren met behulp van Postman.

Als Dexter de authenticatie wilt testen moet hij beschikken over de volgende gegevens:

• Het Azure AD endpoint met daarin het tenant-id van de Azure AD service binnen MMPD;
• De scope (aangemaakt binnen de stap “Register an application in Azure AD to represent the API“;
• De client-id van de app registratie;
• De client-secret van de app registratie, zie de Microsoft document voor het aanmaken van de secret.

Zie hieronder een voorbeeld waarin we succesvol een bearer token ophalen.

Stap 2: bewijst opvragen in combinatie met het bearer token

Nu we een geldig bearer token hebben kunnen we daadwerkelijk de moordzaken opvragen. Ik deel hieronder een screenshot waarin twee vormen van authenticatie de aandacht krijgen:

• Het bearer token;
• De subscription key (standaard feature van Azure API Management)

Zie ook mijn blog voor meer informatie over de subscription key voor zorgvuldig gebruik van de key.

Oei… Dat zijn niet de minst ingrijpende moordzaken:

• The Ice Truck Killer;
• The Bay Harbor Butcher;
• The Trinity Killer.

Mijn favoriet? By far de Bay Harbor Butcher 🙂 .

Een goede stap maar…

Voor de oplettende lezer kunnen we acties nu herleiden naar een applicatie op basis van de app registration (client-id en client-secret) maar nog niet naar een daadwerkelijk levende identiteit.

Als enkel Dexter toegang heeft tot de applicatie is het een prima oplossing maar als er meerdere medewerkers van MMPD de applicatie kunnen gebruiken blijft er toch een grijs gebied. Het grijze gebied gaan we in een volgende blog oplossen door gebruik van persoonlijke identiteiten.

May the force be with you! 🙂