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

Edge for Private Cloud v4.18.05

במסמך הזה נסביר איך מפעילים אחזור וביטול של אסימוני גישה מסוג 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 לפי מזהה משתמש ומזהה אפליקציה

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

ההליך להפעלת גישה לטוקן

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

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

צריך להפעיל את הגישה לטוקנים בנפרד לכל ארגון. קוראים ל-API PUT שבהמשך לכל ארגון שבו רוצים להפעיל אחזור וביטול של אסימוני גישה מסוג 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 על סמך מזהה משתמש או מזהה אפליקציה. כדי לשלוט בגישה, מגדירים הרשאות אחזור והרשאות הטמעה למשאב ‎ /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 הבאה כדי לתת את ההרשאות get ו-put למשאב /oauth2 ב-opsadmin. מחליפים את הערך 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
  • שימוש במשתנה תהליך שמספק את מזהה משתמש הקצה