Edge for Private Cloud v. 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" }
میاناهای برنامه‌سازی کاربردی برای بازیابی و فسخ کردن کدهای دسترسی OAuth 2.0 براساس شناسه کاربر و شناسه برنامه
از میاناهای برنامه‌سازی کاربردی زیر برای دسترسی به کدهای OAuth براساس شناسه کاربر، شناسه برنامه، یا هر دو استفاده کنید:
- دریافت کد دسترسی OAuth 2.0 با شناسه کاربر نهایی یا شناسه برنامه
- لغو کردن OAuth 2.0 کد دسترسی براساس شناسه کاربر نهایی یا شناسه برنامه
رویه فعال کردن دسترسی به کد
از روش زیر برای فعال کردن بازیابی و ابطال کدهای دسترسی OAuth 2.0 براساس شناسه کاربر نهایی و شناسه برنامه استفاده کنید.
مرحله ۱: فعال کردن پشتیبانی از دسترسی به کد برای سازمان
باید دسترسی به کد را برای هر سازمان به‌طور جداگانه فعال کنید. برای هر سازمانی که می‌خواهید واکشی و ابطال ژتون‌های دسترسی OAuth 2.0 را براساس شناسه کاربر نهایی یا شناسه برنامه فعال کنید، «میانای برنامه کاربردی» زیر را فراخوانی کنید.
کاربری که تماس زیر را برقرار می‌کند باید نقش orgadmin یا opsadmin را برای سازمان داشته باشد. مقادیر موجود در {آکولاد} را با مقادیر ویژه سازمانتان جایگزین کنید:
> 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}
مرحله ۲: تنظیم اجازه‌های نقش opsadmin در سازمان
فقط نقش‌های orgadmin و opsadmin در یک سازمان باید اجازه داشته باشند تا براساس شناسه کاربر یا شناسه برنامه، توکن‌های OAuth 2.0 را بازیابی (HTTP GET) و باطل (HTTP PUT) کنند. برای کنترل دسترسی، اجازه‌های دریافت و ارسال را در منبع /oauth2 برای سازمان تنظیم کنید. آن منبع نشانی وبی به این شکل دارد:
https://<ms-ip>:8080/v1/organizations/{org_name}/oauth2نقش orgadmin باید ازقبل اجازه‌های لازم را داشته باشد. برای نقش opsadmin برای منبع /oauth2، اجازه‌ها باید به‌شکل زیر باشد: این:
<ResourcePermission path="/oauth2">
<Permissions>
<Permission>get</Permission>
<Permission>put</Permission>
</Permissions>
</ResourcePermission>می‌توانید از فراخوانی دریافت اجازه برای میانای برنامه‌سازی کاربردی تک‌منبع برای دیدن اینکه کدام نقش‌ها برای منبع /oauth2 اجازه دارند استفاده کنید.
براساس پاسخ، می‌توانید از تماس‌های «میانای برنامه‌سازی کاربردی» افزودن اجازه‌های منبع به نقش و حذف اجازه منبع برای اعمال هرگونه اصلاح لازم در اجازه‌های منبع /oauth2 استفاده کنید.
از دستور cURL زیر برای دادن نقش opsadmin اجازه‌های دریافت و قرار دادن برای منبع /oauth2 استفاده کنید. مقادیر داخل {آکولاد} را با مقادیر ویژه سازمانتان جایگزین کنید:
> 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 استفاده کنید. مقادیر موجود در {آکولاد} را با مقادیر ویژه سازمانتان جایگزین کنید:
> 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}
مرحله ۳: خصوصیت 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
- از متغیر جریانی که شناسه کاربر نهایی را ارائه می‌دهد استفاده کنید