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

Edge for Private Cloud v. 4.17.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 לפי מזהה משתמש ומזהה אפליקציה

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

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

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

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

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

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

המשתמש שמבצע את הקריאה הבאה צריך להיות בתפקיד orgadmin או opsadmin בארגון. מחליפים את הערכים ב-{curly braces} בערכים הספציפיים לארגון:

> curl -H "Content-type:text/xml" -X POST \
  https://<ms-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 {userEmail}:{mypassword}

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

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

https://<ms-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. מחליפים את הערכים ב-{curly braces} בערכים הספציפיים לארגון:

> curl -X POST -H 'Content-type:application/xml' \
  http://<ms-ip>:8080/v1/organizations/{org}/userroles/opsadmin/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions>
        <Permission>get</Permission>
        <Permission>put</Permission>
      </Permissions>
    </ResourcePermission>' \
  -u {USEREMAIL}:{PWD} 

משתמשים בפקודת ה-cURL הבאה כדי לבטל את ההרשאות get ו-put למשאב /oauth2 מתפקידים שאינם orgadmin ו-opsadmin. מחליפים את הערכים ב-{curly braces} בערכים הספציפיים לארגון:

> curl -X DELETE -H 'Content-type:application/xml' \
  http://<msip>:8080/v1/organizations/{org-name}/userroles/{roles}/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions></Permissions>
    </ResourcePermission>' \
   -u {USEREMAIL}:{PWD} 

שלב 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
• שימוש במשתנה תהליך שמספק את מזהה משתמש הקצה