הפעלת גישה לאסימוני OAuth 2.0 לפי מזהה משתמש ומזהה אפליקציה

Edge for Private Cloud גרסה 4.19.01

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

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

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

כברירת מחדל, כש-Edge יוצר אסימון גישה מסוג OAuth 2.0, האסימון הוא בפורמט הבא:

{
  "issued_at" : "1421847736581",
  "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
  "scope" : "READ",
  "status" : "approved",
  "api_product_list" : "[PremiumWeatherAPI]",
  "expires_in" : "3599",
  "developer.email" : "tesla@weathersample.com",
  "organization_id" : "0",
  "token_type" : "BearerToken",
  "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
  "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
  "organization_name" : "myorg",
  "refresh_token_expires_in" : "0",
  "refresh_count" : "0"
}

שימו לב לנקודות הבאות:

• השדה application_name מכיל את ה-UUID של האפליקציה שמשויכת לאסימון. אם מפעילים את האחזור והביטול של אסימוני גישה מסוג OAuth 2.0 לפי מזהה אפליקציה, זהו מזהה האפליקציה שבו השתמשת.
• השדה access_token מכיל את הערך של אסימון הגישה מסוג OAuth 2.0.

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

מזהה משתמש הקצה הוא המחרוזת שבה Edge משתמש כמזהה המפתח, ולא כתובת האימייל של המפתח. address. אפשר לאתר את מזהה המפתח לפי כתובת האימייל של המפתח באמצעות קריאה ל-API למפתחים.

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

{
  "issued_at" : "1421847736581",
  "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
  "scope" : "READ",
  "app_enduser" : "6ZG094fgnjNf02EK",
  "status" : "approved",
  "api_product_list" : "[PremiumWeatherAPI]",
  "expires_in" : "3599",
  "developer.email" : "tesla@weathersample.com",
  "organization_id" : "0",
  "token_type" : "BearerToken",
  "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
  "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
  "organization_name" : "myorg",
  "refresh_token_expires_in" : "0",
  "refresh_count" : "0"
}

ממשקי API לאחזור וביטול אסימוני גישה מסוג OAuth 2.0 לפי מזהה משתמש ומזהה אפליקציה

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

• קבלת OAuth 2.0 אסימון גישה לפי מזהה משתמש קצה או מזהה אפליקציה
• ביטול OAuth 2.0 אסימון גישה לפי מזהה משתמש קצה או מזהה אפליקציה

התהליך להפעלת גישה לאסימון

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

שלב 1: הפעלת תמיכה בגישה לאסימונים לארגון

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

המשתמש שמבצע את הקריאה הבאה חייב להיות בתפקיד orgadmin או opsadmin לארגון. מחליפים את values בטקסט ספציפי לארגון ערכים:

curl -H "Content-type:text/xml" -X POST \
  https://management_server_IP;:8080/v1/organizations/org_name \
  -d '<Organization name="org_name">
      <Properties>
        <Property name="features.isOAuthRevokeEnabled">true</Property>
        <Property name="features.isOAuth2TokenSearchEnabled">true</Property>
      </Properties>
    </Organization>' \
  -u USER_EMAIL:PASSWORD

שלב 2: הגדרת הרשאות לתפקיד opsadmin בארגון

רק התפקידים orgadmin ו-opsadmin בארגון צריכות לקבל הרשאות לאחזור (HTTP GET) ולבטל (HTTP PUT) אסימוני OAuth 2.0 על סמך לפי מזהה משתמש או מזהה אפליקציה. כדי לשלוט בגישה, צריך להגדיר הרשאות get ולהעניק הרשאות למשאב /oauth2 עבור לארגון. למשאב הזה יש כתובת URL בתבנית:

https://management_server_IP:8080/v1/organizations/org_name/oauth2

לתפקיד orgadmin כבר צריכות להיות ההרשאות הנדרשות. עבור תפקיד opsadmin למשאב /oauth2, ההרשאות אמורות להיראות כך הזה:

<ResourcePermission path="/oauth2">
  <Permissions>
    <Permission>get</Permission>
    <Permission>put</Permission>
  </Permissions>
</ResourcePermission>

תוכלו להשתמש הרשאה לקריאה ל-Single Resource API כדי לראות לאילו תפקידים יש הרשאות משאב /oauth2.

בהתאם לתשובה, אפשר להשתמש בלחצן הוספת הרשאות למשאבים בתפקידים וגם קריאות ל-API של Permissions for Resource לבצע את השינויים הדרושים ב- /oauth2 בהרשאות המשאבים.

משתמשים בפקודה curl הבאה כדי להקצות את התפקיד opsadmin ההרשאות get ו-put למשאב /oauth2. החלפה values עם הערכים הספציפיים לארגון שלך:

curl -X POST -H 'Content-type:application/xml' \
  http://management_server_IP:8080/v1/organizations/org_name/userroles/opsadmin/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions>
        <Permission>get</Permission>
        <Permission>put</Permission>
      </Permissions>
    </ResourcePermission>' \
  -u USEREMAIL:PASSWORD

משתמשים בפקודה curl הבאה כדי לבטל את get ואת put הרשאות למשאב /oauth2 מתפקידים אחרים מלבד orgadmin ו-opsadmin. מחליפים את values ב ערכים ספציפיים לארגון:

curl -X DELETE -H 'Content-type:application/xml' \
  http://management_server_IP:8080/v1/organizations/org_name/userroles/roles/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions></Permissions>
    </ResourcePermission>' \
   -u USEREMAIL:PASSWORD

שלב 3: הגדרה המאפיין oauth_max_search_limit

עליך לוודא שconf_keymanagement_oauth_max_search_limit נכס ב-/opt/apigee/customer/application/management-server.properties מוגדר ל-100:

conf_keymanagement_oauth_max_search_limit = 100

אם הקובץ הזה לא קיים, יוצרים אותו.

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

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

/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

שלב 4: מגדירים את מדיניות OAuth 2.0 שיוצרת אסימונים כך שיכללו מזהה של משתמש קצה

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

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

מדיניות OAuth 2.0 שלמטה, שנקראת GenerateAccessTokenClient, יוצרת גישת OAuth 2.0 ב-Assistant. חשוב לשים לב שהוספת התג <AppEndUser> בגופן מודגש שמציין את הטקסט המשתנה שמכיל את המזהה של משתמש הקצה:

<OAuthV2 async="false" continueOnError="false" enabled="true" name="GenerateAccessTokenClient">
    <DisplayName>OAuth 2.0.0 1</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <SupportedGrantTypes>
         <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
    <GrantType>request.queryparam.grant_type</GrantType> 
    <AppEndUser>request.header.appuserID</AppEndUser> 
    <ExpiresIn>960000</ExpiresIn>
</OAuthV2>

לאחר מכן אפשר להשתמש בפקודה הבאה של curl כדי ליצור גישת OAuth 2.0 האסימון, מעביר את מזהה המשתמש ככותרת appuserID:

curl -H "appuserID:6ZG094fgnjNf02EK" \
  https://myorg-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials \
  -X POST -d 'client_id=k3nJyFJIA3p62TKIkLO6OJNXFmP&client_secret=gk5K5lIp943AY4'

בדוגמה הזו, השדה appuserID מועבר ככותרת בקשה. אפשר לעבור כחלק מבקשה בדרכים רבות. לדוגמה, במקום זאת, אפשר:

• שימוש במשתנה פרמטר של טופס: request.formparam.appuserID
• משתמשים במשתנה זרימה שמספק את המזהה של משתמש הקצה