הגדרת אימות של מפתח API

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

כדי להגדיר אימות של מפתח API עבור API, צריך לצרף מדיניות מסוג Verify API Key. ההגדרה הנדרשת היחידה עבור מדיניות VerifyAPIKey היא המיקום הצפוי של מפתח ה-API בבקשת הלקוח. ה-proxy ל-API יבדוק את המיקום שציינתם ויחלץ את מפתח ה-API. אם מפתח ה-API לא נמצא במיקום הצפוי, מוצגת שגיאה והבקשה נדחית. מפתחות API יכולים להיות פרמטר של שאילתה, פרמטר של טופס או כותרת HTTP.

לדוגמה, הגדרת המדיניות שבהמשך מגדירה את המיקום הצפוי של המפתח כפרמטר של שאילתה בשם apikey. בקשה שמועברת בהצלחה צריכה להציג את מפתח ה-API כפרמטר של שאילתה שמצורף לבקשה, לדוגמה,?apikey=Y7yeiuhcbKJHD790.

כדי לאמת מפתחות API, יוצרים את המדיניות הבאה:

<VerifyAPIKey name="APIKeyValidation">
  <APIKey ref="request.queryparam.apikey"/>
</VerifyAPIKey>

אפשר לצרף את המדיניות הזו לכל API שרוצים להגן עליו.

תיעוד מקיף של סוג המדיניות הזה זמין בנושא ההפניה למדיניות, VerifyAPIKey policy.

שרתי proxy של API מעבירים באופן אוטומטי את כל כותרות ה-HTTP והפרמטרים של השאילתות שמופיעים בבקשה. לכן, אחרי שמפתח ה-API מאומת, מומלץ להסיר אותו מההודעה כדי שהוא לא יישלח דרך הרשת לשירות לקצה העורפי. אפשר לעשות את זה באמצעות מדיניות מסוג AssignMessage באופן הבא:

<AssignMessage name="StripApiKey">
    <DisplayName>Remove Query Param</DisplayName>
    <Remove>
        <QueryParams>
            <QueryParam name="apikey"/>
        </QueryParams>
    </Remove>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"></AssignTo>
</AssignMessage>

צירוף מדיניות

צריך לצרף את כללי המדיניות ל-Flow של שרת proxy ל-API בתור שלבי עיבוד. החלת המדיניות על הבקשה PreFlow מאפשרת לאמת את מפתחות ה-API בכל בקשה שמתקבלת מ-proxy ל-API מאפליקציית לקוח. אחרי האימות, מפתח ה-API מוסר מהבקשה היוצאת.

מצרפים את המדיניות ל-ProxyEndpoint של שרת ה-proxy ל-API שרוצים להגן עליו, באופן הבא:

<ProxyEndpoint name="default">
  <PreFlow>
    <Request>
      <Step><Name>APIKeyValidation</Name></Step>
      <Step><Name>StripApiKey</Name></Step>
    </Request>
  </PreFlow>

אחרי שמצרפים את המדיניות, פורסים את proxy ל-API.

שליחת בקשה עם מפתח API תקין

אדמינים בארגון יכולים לאחזר את מפתח ה-API של כל אפליקציה באופן הבא:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/developers/$DEVELOPER_EMAIL/apps/$APP \
  -H "Authorization: Bearer $TOKEN"

‫$TOKEN מוגדר לאסימון הגישה מסוג OAuth 2.0, כפי שמתואר במאמר קבלת אסימון גישה מסוג OAuth 2.0. מידע על האפשרויות curl שבהן נעשה שימוש בדוגמה הזו מופיע במאמר שימוש ב-curl. תיאור של משתני הסביבה שבהם אפשר להשתמש מופיע במאמר בנושא הגדרת משתני סביבה לבקשות API של Apigee.

פרופיל האפליקציה שמוחזר עבור הקריאה הזו מספק את טוקן הצרכן (מפתח API) ואת הסוד. ערך טוקן הצרכן הוא הערך שבו משתמשים למפתח ה-API בבקשה ל-API המוגן.

לדוגמה, בקשה שלא כוללת מפתח API גורמת לכשל בהרשאה.

curl http://apitest.examplepetstore.com/weather/forecastrss?w=12797282

הודעת הכשל מציינת שהמדיניות בדקה אם יש מפתח API, אבל לא מצאה מפתח תקין:

OAuth Failure : Could not resolve the app key with variable request.queryparam.apikey

כשמפתח הצרכן של האפליקציה נכלל כפרמטר של שאילתה, התוצאה הצפויה היא הרשאה מוצלחת:

curl http://apitest.examplepetstore.com/weather/forecastrss?w=12797282&"apikey=PulSCqMnXGchW0pC0s5o9ngHVTWMeLqk"

התוצאה הצפויה היא תגובה מוצלחת משירות מזג האוויר.

שינוי הערך של מפתח ה-API בבקשה גורם לכשל בהרשאה:

curl http://apitest.examplepetstore.com/weather?forecastrss?w=12797282&"apikey=PulSCqMnXGchW0"

התוצאות:

OAuth Failure : Consumer Key is Invalid