אנטי-דפוס: הגדרת מועד תפוגה ללא תפוגה של אסימוני OAuth

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

באמצעות Apigee Edge מספקת מסגרת OAuth 2.0 לממשקי API מאובטחים. OAuth2 היא אחת מסכימות האימות וההרשאות הפופולריות ביותר בתקן פתוח שמבוססות על אסימונים. הוא מאפשר לאפליקציות לקוח לגשת לממשקי API מטעם משתמשים בלי לדרוש מהמשתמשים לחשוף את שם המשתמש והסיסמה שלהם.

Apigee Edge מאפשר למפתחים ליצור אסימוני גישה ו/או רענון על ידי הטמעה של כל אחד מארבעת סוגי ההרשאות של OAuth2 – פרטי כניסה של לקוח, סיסמה, משתמע וקוד הרשאה - באמצעות מדיניות OAuthv2. אפליקציות לקוח משתמשות באסימוני גישה כדי לצרוך ממשקי API מאובטחים. לכל אסימון גישה יש זמן תפוגה משלו. אפשר להגדיר את המועד הזה במדיניות OAuthv2.

אסימוני רענון ניתנים באופן אופציונלי יחד עם אסימוני גישה עם חלק מסוגי המענק. אסימוני הרענון משמשים לקבלת אסימוני גישה חדשים ותקפים אחרי שיפוג התוקף של אסימון הגישה המקורי או שהוא בוטל. אפשר להגדיר את מועד התפוגה של אסימוני הרענון גם במדיניות OAuthv2.

הדפוס הזה קשור לדפוס של הגדרת זמן תפוגה ארוך לאסימוני OAuth.

דוגמת עיצוב

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

בדוגמה הבאה של מדיניות OAuthV2, חסרה הגדרה אישית עבור <RefreshTokenExpiresIn>: 

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <!--<RefreshTokenExpiresIn> is missing -->
    <SupportedGrantTypes>
      <GrantType>password</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

בדוגמה שלמעלה:

  • אסימון הגישה מוגדר עם זמן תפוגה סביר של 30 דקות.
  • תאריך התפוגה של אסימון הרענון לא מוגדר.
  • אסימון הרענון נשמר במאגר הנתונים (Cassandra) לתמיד, וגורם להצטברות נתונים.
  • אפשר להשתמש באסימון רענון שהופק בלי תאריך תפוגה, כדי ליצור אסימוני גישה ללא הגבלת זמן.
  • אם התנועה ל-API הזה כוללת 10 בקשות בשנייה, הוא יכול ליצור עד 864,000 אסימונים ביום.

השפעה

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

שיטה מומלצת

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

שיטות מומלצות ספציפית ללקוחות Edge ללקוחות ענן פרטי

בקטע מתוארות שיטות מומלצות באופן ספציפי ללקוחות Edge ללקוחות ענן פרטי.

ציון תפוגת ברירת המחדל של אסימון הרענון

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

  1. בצומת של מעבד הודעות, אפשר לערוך או ליצור את קובץ שינוי ההגדרות האישיות $APIGEE_ROOT/customer/application/message-processor.properties. יש לוודא שהמשתמש apigee יכול לקרוא את הקובץ הזה.
  2. מוסיפים את השורה הבאה לקובץ: 
    conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
    פעולה זו תגדיר את תאריך התפוגה של אסימון הרענון המשמש כברירת מחדל, אם לא צוין במדיניות, למשך שעה אחת. אפשר לשנות את ערך ברירת המחדל הזה בהתאם לצרכים של העסק.
  3. מפעילים מחדש את שירות מעבד ההודעות: 
    apigee-service edge-message-processor restart
  4. חוזרים על השלבים שלמעלה בכל הצמתים של עיבוד ההודעות, אחד בכל פעם.

שיטות מומלצות ב-Cassandra

כדאי לנסות לשדרג לגרסה האחרונה של Apigee הזמינה באופן ציבורי. Apigee ממשיכה לפרסם תיקונים ושיפורים שממשיכים לשפר ולבצע אופטימיזציה של ניהול האסימונים ב-Apigee. ב-Apigee, אסימוני הגישה והרענון מאוחסנים ב-Cassandra בתוך מרחב המפתחות "kms". חשוב לוודא ששיטת הדחיסה של מרחב המפתחות הזה מוגדרת כ-LeveledCompactionStrategy. עליך לבדוק שהמדדים הבאים לא נמצאים:
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_organization_name_idx#f0f0f0 ו-
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_status_idx

אפשר גם להקטין את הערך gc_grace_seconds בטבלה kms.oauth_20_access_tokens מברירת המחדל של 10 ימים לערך נמוך יותר (למשל, 3 ימים), כדי להבטיח שהמצבות שנוצרו בעקבות מחיקת האסימונים יימחקו ממאגר הנתונים מהר יותר.

קריאה נוספת