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

Edge for Private Cloud نسخه 4.17.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 از آن به عنوان شناسه توسعه دهنده استفاده می کند، نه آدرس ایمیل توسعه دهنده. با استفاده از تماس 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"
}

APIهایی برای بازیابی و لغو نشانه‌های دسترسی OAuth 2.0 توسط شناسه کاربر و شناسه برنامه

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

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

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

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

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

کاربری که تماس زیر را برقرار می کند باید در نقش 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) و لغو (HTTP PUT) نشانه‌های OAuth 2.0 بر اساس شناسه کاربر یا شناسه برنامه داده شود. برای کنترل دسترسی، مجوزهای دریافت و قرار دادن بر روی منبع /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>

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

بر اساس پاسخ، می توانید از Add Permissions for Resource to a Role و Delete Permission for Resource API برای انجام هرگونه تنظیمات لازم در مجوزهای منبع /oauth2 استفاده کنید.

از دستور cURL زیر برای دادن مجوز به نقش opsadmin برای منبع /oauth2 استفاده کنید. مقادیر موجود در {braces curly} را با مقادیر خاص سازمان خود جایگزین کنید:

> 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 زیر برای لغو مجوزهای دریافت و قرار دادن منبع /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
  • از یک متغیر جریان استفاده کنید که شناسه کاربر نهایی را ارائه می کند