API-k biztonságossá tétele előfizetések használatával
Amikor API-kat tesz közzé az API Management használatával, egyszerű és gyakori, hogy az előfizetési kulcsok használatával biztonságosan hozzáfér ezekhez az API-khoz. A közzétett API-k használatához szükséges fejlesztőknek érvényes előfizetési kulcsot kell tartalmazniuk a HTTP-kérésekben, amikor hívásokat kezdeményeznek az adott API-khoz. Ellenkező esetben az API Management-átjáró azonnal elutasítja a hívásokat. A háttérszolgáltatások nem továbbítják őket.
Az API-k eléréséhez szükséges előfizetési kulcs lekérése. Az előfizetés lényegében egy elnevezett tároló az előfizetési kulcsok párjának. Azok a fejlesztők, akiknek a közzétett API-kat kell használniuk, előfizetéseket szerezhetnek be. És nincs szükségük az API-közzétevők jóváhagyására. Az API-közzétevők közvetlenül is létrehozhatnak előfizetéseket az API-felhasználók számára.
Megjegyzés:
Az API Management az API-khoz való hozzáférés biztosításának egyéb mechanizmusait is támogatja, többek között az OAuth2.0-t, az ügyféltanúsítványokat és az IP-engedélyezési listákat.
Előfizetések és azonosítók
Az előfizetői azonosítók egyedi, automatikusan létrehozott kulcsok, amelyeket az ügyfélkérelmek fejlécén keresztül vagy lekérdezésisztring-paraméterként kell megadni. Az azonosító közvetlenül kapcsolódik egy előfizetéshez, amelynek a hatóköre többféle is lehet. Az előfizetések lehetővé teszik az engedélyek és szabályzatok nagyobb mértékű kontrollját.
A három fő előfizetési hatókör a következő:
| Scope | Részletek |
|---|---|
| Minden API | Az átjáróból elérhető összes API-ra vonatkozik |
| Egyetlen API | Ez a hatókör egyetlen importált API-ra és annak összes végpontjára vonatkozik |
| Termék | Egy termék egy vagy több, az API Managementben konfigurált API-k gyűjteménye. Egy API-t több termékhez is hozzárendelhet. A termékekre különböző hozzáférési szabályok, használati kvóták és használati feltételek vonatkozhatnak. |
A védett API-kat hívó alkalmazások kérelemhívásaiban szerepelnie kell az azonosítónak.
Bármikor újra létrehozhatja az előfizetői azonosítókat, például ha azt gyanítja, hogy az azonosító jogosulatlan felhasználókkal lett megosztva.
Minden előfizetéshez két azonosító tartozik, egy elsődleges és egy másodlagos. Két azonosítóval könnyebb a dolga, amikor az egyiket újra létre kell hozni. Ha például módosítani szeretné az elsődleges azonosítót, és el szeretné kerülni az állásidőt, a másodlagos azonosítót használhatja az alkalmazásokban.
Azokban a termékekben, ahol engedélyezettek az előfizetések, az ügyfeleknek meg kell adniuk egy azonosítót, amikor a termékben lévő API-kat hívják. A fejlesztők egy előfizetési kérés elküldésével szerezhetnek be azonosítót. Ha jóváhagyja a kérést, biztonságos módon kell elküldenie nekik az előfizetői azonosítót, például egy titkosított üzenetben. Ez a lépés az API Management-munkafolyamat fontos része.
API hívása előfizetői azonosítóval
Az alkalmazásoknak minden HTTP-kérésbe bele kell foglalniuk egy érvényes azonosítót, amikor előfizetéssel védett API-végpontokra irányuló hívásokat indítanak. Az azonosítók a kérelem fejlécében vagy az URL-ben, lekérdezési sztringként továbbíthatók.
Az alapértelmezett fejléc neve Ocp-Apim-Subscription-Key, és az alapértelmezett lekérdezési sztring a subscription-key.
Az API-hívások teszteléséhez használhatja a fejlesztői portált vagy a parancssori eszközöket, például a curl parancsot. Íme egy példa egy GET kérelemre a fejlesztői portálon, az előfizetői azonosító fejlécével:
Így helyezheti az azonosítót a kérelem fejlécébe a curl paranccsal:
curl --header "Ocp-Apim-Subscription-Key: <key string>" https://<apim gateway>.azure-api.net/api/path
Példa a curl parancsra, amelyet lekérdezési sztringként helyez azonosítót az URL-címbe:
curl https://<apim gateway>.azure-api.net/api/path?subscription-key=<key string>
Ha az azonosítót nem adja meg a fejlécben vagy lekérdezési sztringként az URL-címben, egy 401 A hozzáférés megtagadva hibaüzenetet kap az API-átjárótól.