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