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

Edge for Private Cloud גרסה 4.16.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 משתמש כמזהה המפתח, ולא כתובת האימייל של המפתח. 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 בארגון. החלפת הערכים בפונקציה {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 בארגון

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

https://<ms-ip>:8080/v1/organizations/{org_name}/oauth2

לתפקיד אדמין ארגוני כבר צריכות להיות ההרשאות הנדרשות. עבור 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. מחליפים את הערכים ב- {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 נכס ב-/<inst_dir>/apigee/customer/application/management-server.properties מוגדר ל-100:

conf_keymanagement_oauth_max_search_limit = 100

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

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

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

> /<inst_rt>/apigee/apigee-service/bin/apigee-service edge-management-server restart
> /<inst_rt>/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
• משתמשים במשתנה זרימה שמספק את המזהה של משתמש הקצה