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

במסמך הזה מוסבר איך מפעילים אחזור וביטול של אסימוני גישה מסוג 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 כמזהה המפתח, ולא כתובת האימייל של המפתח. אפשר לדעת את מזהה המפתח לפי כתובת האימייל של המפתח באמצעות הקריאה'Get Developer 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) וביטול אסימוני OAuth 2.0 (HTTP 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.

בהתאם לתשובה, תוכלו להשתמש בקריאות ל-Add Permissions for Resource to a Role ול- Delete Permission for Resource API כדי לבצע את השינויים הנחוצים בהרשאות המשאבים /oauth2.

כדי לתת לתפקיד opsadmin את ההרשאות get ו-put למשאב /oauth2, צריך להשתמש בפקודה curl הבאה. מחליפים את 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

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