הפעלת גישה לאסימוני 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 משתמש כמזהה המפתח, ולא כתובת האימייל של המפתח. כדי לזהות את מזהה המפתח לפי כתובת האימייל שלו, אפשר להשתמש בקריאה ל-API‏ Get Developer.

אחרי שמגדירים את 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 לפי מזהה משתמש ומזהה אפליקציה

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

איך מפעילים גישה באמצעות טוקן

כדי לאפשר אחזור וביטול של טוקני גישה מסוג 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 ו-put במשאב ‎ /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>

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

בהתאם לתשובה, אתם יכולים להשתמש בקריאות ל-API‏ Add Permissions for Resource to a Role ו- Delete Permission 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 שמשמשת ליצירת טוקני גישה, כך שתכלול את מזהה משתמש הקצה בטוקן. אם תכללו את מזהי משתמשי הקצה בטוקן הגישה, תוכלו לאחזר ולבטל טוקנים לפי מזהה.

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

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