אנטי-דפוס: הגדרת מועד תפוגה ללא תפוגה של אסימוני 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, מה שיוביל לניפוח, לעלייה בשימוש בדיסק ולדחיסות כבדות יותר, ובסופו של דבר יגרום לזמני אחזור של קריאה/כתיבה ב-Cassandra.

שיטה מומלצת

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

שיטות מומלצות ללקוחות Edge for Private Cloud

בקטע הזה מפורטות שיטות מומלצות ללקוחות Edge for Private Cloud.

ציון תפוגה של טוקן רענון כברירת מחדל

כברירת מחדל, אם תפוגה של אסימון רענון לא מצוינת בהגדרת מדיניות, 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 and
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_status_idx

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

קריאה נוספת