فعال کردن دسترسی به کدهای OAuth 2.0 براساس شناسه کاربر و شناسه برنامه

Edge for Private Cloud نسخه ۴.۱۹.۰۱

این سند نحوه فعال کردن بازیابی و ابطال کدهای دسترسی 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"
}

میاناهای برنامه‌سازی کاربردی برای بازیابی و فسخ کردن کدهای دسترسی OAuth 2.0 براساس شناسه کاربر و شناسه برنامه

از میاناهای برنامه‌سازی کاربردی زیر برای دسترسی به کدهای OAuth براساس شناسه کاربر، شناسه برنامه، یا هر دو استفاده کنید:

روال فعال کردن دسترسی به کد

از روش زیر برای فعال کردن بازیابی و ابطال کدهای دسترسی OAuth 2.0 براساس شناسه کاربر نهایی و شناسه برنامه استفاده کنید.

مرحله ۱: فعال کردن پشتیبانی از دسترسی به کد برای سازمان

باید دسترسی با کد را برای هر سازمان به‌طور جداگانه فعال کنید. برای هر سازمانی که می‌خواهید بازیابی و ابطال کدهای دسترسی OAuth 2.0 را براساس شناسه کاربر نهایی یا شناسه برنامه فعال کنید، PUT API زیر را فراخوانی کنید.

کاربری که تماس زیر را برقرار می‌کند باید در نقش 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

مرحله ۲: تنظیم اجازه‌ها برای نقش opsadmin در سازمان

فقط نقش‌های orgadmin و opsadmin در سازمان باید اجازه بازیابی (HTTP GET) و لغو (HTTP PUT) کردن کدهای OAuth 2.0 را براساس شناسه کاربر یا شناسه برنامه داشته باشند. برای کنترل دسترسی، اجازه‌های get و put را در منبع /oauth2 برای سازمان تنظیم کنید. آن منبع نشانی وبی به این شکل دارد:

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>

می‌توانید از فراخوانی دریافت اجازه برای API منبع تکی استفاده کنید تا ببینید کدام نقش‌ها برای منبع /oauth2 اجازه دارند.

براساس پاسخ، می‌توانید از فراخوانی‌های میانای برنامه‌سازی کاربردی افزودن اجازه‌های منبع به نقش و حذف اجازه منبع برای انجام هرگونه اصلاحات لازم در اجازه‌های منبع ‎ /oauth2 استفاده کنید.

از فرمان curl زیر برای دادن نقش opsadmin get و اجازه‌های put برای منبع /oauth2 استفاده کنید. 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

مرحله ۳: تنظیم ویژگی oauth_max_search_limit

مطمئن شوید که ویژگی conf_keymanagement_oauth_max_search_limit در فایل /opt/apigee/customer/application/management-server.properties روی ۱۰۰ تنظیم شده باشد:

conf_keymanagement_oauth_max_search_limit = 100

اگر این فایل وجود ندارد، آن را ایجاد کنید.

این ویژگی اندازه صفحه مورداستفاده هنگام واکشی کردن توکن‌ها را تنظیم می‌کند. Apigee مقدار ۱۰۰ را توصیه می‌کند، اما می‌توانید آن را به‌دلخواه خودتان تنظیم کنید.

در نصب جدید، این ویژگی باید ازقبل روی ۱۰۰ تنظیم شده باشد. اگر مجبورید مقدار این ویژگی را تغییر دهید، «سرور مدیریت» و «پردازشگر پیام» را بااستفاده از این فرمان‌ها بازراه‌اندازی کنید:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

مرحله ۴: خط‌مشی 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
  • از متغیر جریانی استفاده کنید که شناسه کاربر نهایی را ارائه می‌دهد