הטמעה של סוג מתן הסיסמה

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X.
מידע

סוג המענק של בעלי המשאב (או 'סיסמה') משמש בעיקר במקרים שבהם האפליקציה מהימנה מאוד. בהגדרה הזו, המשתמש מספק לאפליקציית הלקוח את פרטי הכניסה של שרת המשאבים (שם משתמש/סיסמה) והבקשה שלו נשלחת ל-Apigee Edge בבקשת אסימון גישה. שרת זהויות מאמת את פרטי הכניסה, ואם הם תקינים, Edge ינפיק אסימון גישה ויחזיר אותו לאפליקציה.

מידע על נושא זה

בנושא הזה יש תיאור כללי וסקירה כללית של תהליך סוג המענק של הסיסמה של בעלי משאב OAuth 2.0, ומתואר איך להטמיע את התהליך הזה ב-Apigee Edge.

דוגמאות שעשויות להועיל לך

  • בקשת accesstoken: סוג מתן סיסמה: מראה איך ליצור בקשה לאסימון, להגדיר את מדיניות OAuthV2 לסוג מתן הסיסמה ואיך להגדיר נקודת קצה (endpoint) של המדיניות ב-Edge.
  • oauth-validate-key-secret: שרת proxy לדוגמה ב-GitHub שאפשר לפרוס ב-Edge ולנסות. זו דוגמה מקצה לקצה שמציגה את סוג מתן הסיסמה. זוהי שיטה מומלצת לאימות פרטי הכניסה של אפליקציית הלקוח (מפתח/סוד) לפני שליחת פרטי הכניסה של המשתמש לספק זהויות.

וידאו

סרטון: כדאי לצפות בסרטון הזה על הטמעת סוג של הענקת סיסמה.

תרחישים לדוגמה

סוג ההרשאה הזה מיועד לאפליקציות מהימנות או עם הרשאות גבוהות, כי המשתמש נדרש לספק לאפליקציה את פרטי הכניסה של שרת המשאבים שלו. בדרך כלל, האפליקציה מספקת מסך התחברות שבו המשתמשים מזינים את פרטי הכניסה.

תרשים זרימה

תרשים הזרימה הבא ממחיש את התהליך של סוג המענק של הסיסמה של בעלי המשאב, כש-Apigee Edge משמש כשרת ההרשאות.

טיפ: כדי לראות גרסה מוגדלת של הדיאגרמה הזו, יש ללחוץ עליה לחיצה ימנית ולפתוח אותה בכרטיסייה חדשה, או לשמור אותה ולפתוח אותה במציג התמונות.

שלבים בתהליך של סוג מתן הסיסמה

זהו סיכום של השלבים הנדרשים כדי להטמיע את סוג הרשאת הסיסמה, כאשר Apigee Edge משמש כשרת ההרשאות.

דרישה מוקדמת: אפליקציית הלקוח צריכה להיות רשומה ב-Apigee Edge כדי לקבל את מזהה הלקוח ואת המפתחות הסודיים של הלקוח. לפרטים נוספים, יש לעיין במאמר רישום של אפליקציות לקוח.

1. המשתמש מתחיל את התהליך ומזין את פרטי הכניסה

כשהאפליקציה צריכה לגשת למשאבים המוגנים של המשתמש (לדוגמה, המשתמש לוחץ על לחצן באפליקציה), הוא מופנה לטופס התחברות.

2. האפליקציה מבקשת אסימון גישה מ-Apigee Edge

האפליקציה שולחת בקשה לאסימון גישה, כולל פרטי הכניסה של המשתמש, לנקודת קצה של GenerateAccessToken ב-Apigee Edge.

הנה דוגמה לבקשת POST, שכוללת את הפרמטרים הנדרשים לסוג המענק הזה:

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

לחלופין, אפשר לבצע את הפקודה הבאה, באמצעות האפשרות -u, כדי ליצור כותרת אימות בסיסי בקידוד base64 עבורכם.

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

(כל אחת מהפקודות האלה צריכה להיות בשורה אחת).

פרטי הכניסה של המשתמש נמצאים בפרמטרים של הטופס, ופרטי הכניסה של הלקוח מקודדים בכותרת האימות הבסיסי של ה-HTTP. לתיאור מפורט של הקריאה הזו ל-API, כולל פרטים על הכותרת הנדרשת של Basic Auth, אפשר לעיין בקטע 'הענקת סיסמה' במאמר בקשה לאסימוני גישה וקודי הרשאה.

3. Edge מאמת את אפליקציית הלקוח

לפני שליחת שם המשתמש והסיסמה של המשתמש לספק זהויות, Edge צריך לדעת שאפליקציית הלקוח ששולחת את הבקשה היא אפליקציה מהימנה וחוקית. אחת הדרכים לעשות זאת היא להשתמש באימות של מפתח API בקריאה ל-API. במקרים מסוימים, כדאי לאמת גם את מפתח הלקוח וגם את סוד הלקוח. אפשר להיעזר בשרת proxy לדוגמה שממחיש את השיטה הזו ב מאגר api-platform-samples ב-GitHub.

4. Edge מעבד את פרטי הכניסה

אחרי שאפליקציית הלקוח תאומת, תוכלו להשתמש במדיניות JavaScript או יתרונות מרכזיים של השירות כדי לקרוא לשירות הזהויות, ולשלוח את פרטי הכניסה של המשתמש. לדוגמה, הוא יכול להיות שירות LDAP או כל שירות אחר שרוצים להשתמש בו לאימות פרטי הכניסה. לפרטים נוספים על כללי המדיניות האלה, אפשר לעיין במדיניות לחילוץ משתנים ובמדיניות JavaScript.

אם שירות הזהויות מאמת את פרטי הכניסה ומחזיר תגובה 200, Edge ימשיך לעבד את הבקשה. אחרת, Edge יפסיק את העיבוד ויחזיר שגיאה לאפליקציית הלקוח.

5. מדיניות OAuthV2 מבוצעת

אם פרטי הכניסה תקינים, השלב הבא בעיבוד הוא להפעיל מדיניות OAuthV2 שהוגדרה לסוג מתן הסיסמה. כאן מוצגת דוגמה. הרכיבים <UserName> ו-<PassWord> הם רכיבי חובה, ואפשר לאחזר אותם ממשתני הזרימה שנשמרו במדיניות extracts. לקבלת מידע מפורט על המדיניות הזו, ראו מדיניות OAuthV2.

<OAuthV2 name="GetAccessToken">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn>360000000</ExpiresIn> 
  <SupportedGrantTypes> 
     <GrantType>password</GrantType> 
  </SupportedGrantTypes> 
  <GrantType>request.queryparam.grant_type</GrantType> 
  <UserName>login</UserName>
  <PassWord>password</PassWord>
  <GenerateResponse/> 
</OAuthV2>

אם המדיניות הזו מצליחה, המערכת יוצרת תגובה ללקוח שמכיל אסימון גישה. התשובה היא בפורמט JSON. נראה דוגמה. חשוב לשים לב שהפרמטר access_token הוא אחד מהרכיבים:

{
    "issued_at": "1420258685042",
    "scope": "READ",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "refresh_token_issued_at": "1420258685042",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799",
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6",
    "organization_name": "docs",
    "refresh_token_expires_in": "0",
    "refresh_count": "0"
}

6. הלקוח קורא ל-API המוגן

עכשיו, עם קוד גישה חוקי, הלקוח יוכל לבצע קריאות ל-API המוגן. בתרחיש הזה, בקשות נשלחות ל-Apigee Edge (שרת ה-proxy), ו-Edge אחראית לאמת את אסימון הגישה לפני העברת הקריאה ל-API לשרת משאבי היעד. אסימוני הגישה מועברים בכותרת Authorization. לדוגמה:

$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6
" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282