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

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

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

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

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

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

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

باید دسترسی به کد را برای هر سازمان به‌طور جداگانه فعال کنید. برای هر سازمانی که می‌خواهید واکشی و ابطال ژتون‌های دسترسی 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

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

فقط نقش‌های orgadmin و opsadmin در یک سازمان باید اجازه داشته باشند تا براساس شناسه کاربر یا شناسه برنامه، نشان‌های OAuth 2.0 را بازیابی (HTTP GET) و باطل (HTTP 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
• از متغیر جریانی که شناسه کاربر نهایی را ارائه می‌دهد استفاده کنید