הטמעה של סוג ההרשאה password

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

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

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

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

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

דוגמאות שיכולות להיות שימושיות

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

וידאו

סרטון: סרטון שמסביר איך להטמיע את סוג ההרשאה password grant.

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

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

תרשים זרימה

הדיאגרמה הבאה ממחישה את תהליך ההרשאה מסוג סיסמה של בעל המשאב, כש-Apigee משמש כשרת ההרשאות.

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

תהליך ההרשאה של סיסמת בעל המשאב.

השלבים בתהליך של סוג ההרשאה 'סיסמה'

הנה סיכום של השלבים הנדרשים להטמעה של סוג ההרשאה password (סיסמה) במקרים שבהם Apigee משמש כשרת ההרשאות.

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

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

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

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

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

זוהי דוגמה לבקשת 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 של curl כדי ליצור את כותרת האימות הבסיסי בקידוד 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, כולל פרטים על כותרת האימות הבסיסי הנדרשת, מופיע בקטע 'הרשאת סיסמה' במאמר קבלת טוקנים של OAuth 2.0.

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

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

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

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

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

5. המדיניות OAuthV2 מופעלת

אם פרטי הכניסה תקפים, השלב הבא בעיבוד הוא הפעלת מדיניות OAuthV2 שהוגדרה לסוג ההרשאה password. כאן מוצגת דוגמה. הרכיבים <UserName> ו-<PassWord> הם חובה, ואפשר לאחזר אותם ממשתני הזרימה שנשמרו באמצעות מדיניות ExtractVariables. מידע מפורט על המדיניות הזו זמין במאמר בנושא מדיניות 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 (ה-proxy), ו-Apigee אחראי לאימות של אסימון הגישה לפני העברת הקריאה ל-API לשרת משאב היעד. טוקנים של גישה מועברים בכותרת Authorization. לדוגמה:

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