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