आपको Apigee Edge दस्तावेज़ दिख रहा है.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
इस पेज पर जाएं
Apigee X दस्तावेज़. जानकारी
इस विषय में, हम बाहरी लोगों से जनरेट किए गए ऐक्सेस टोकन इंपोर्ट करने, रीफ़्रेश टोकन, या ऑथराइज़ेशन कोड को Edge टोकन स्टोर पर ले जाते हैं. अगर आप चाहें, तो इस तकनीक का इस्तेमाल Apigee Edge के बाहर जनरेट किए गए टोकन की पुष्टि करने के लिए, Apigee Edge को कॉन्फ़िगर करें.
आम तौर पर, Apigee Edge पर OAuth टोकन जनरेट किया जाएगा और उसे सेव किया जाएगा. साथ ही, उसे कॉलिंग ऐप्लिकेशन. इसके बाद, कॉल करने वाला ऐप्लिकेशन, अनुरोध करने पर उस टोकन को Apigee Edge को वापस दिखाता है service और Apigee Edge - में OAuthV2 नीति के ज़रिए ऑपरेशन = VerifyAccessToken - के साथ - होगा यह पुष्टि करें कि टोकन मान्य है. इस विषय में, Apigee Edge को सेव करने का तरीका बताया गया है ऐसा OAuth टोकन जो कहीं और जनरेट किया गया था, लेकिन टोकन की पुष्टि करने वाले हिस्से में कोई बदलाव नहीं करता, जैसे कि टोकन को Edge से जनरेट किया गया हो.
उदाहरण
अगर आपको तकनीक का उदाहरण देने वाला कोई ऐसा उदाहरण देखना है जिसमें इस विषय में बताए गए हैं. इनके बारे में ज़्यादा जानने के लिए, Apigee डेलिगेट किए गए टोकन मैनेजमेंट का सैंपल.
यह क्या है?
मान लें कि आपके पास एक मौजूदा ऑथराइज़ेशन सिस्टम है और आपको उस सिस्टम के ज़रिए जनरेट किए गए OAuth2 टोकन या कोड वैल्यू के बजाय, उस टोकन या कोड की वैल्यू को जनरेट किया गया है Edge जनरेट होता है. इसके बाद, बदले गए टोकन या कोड का इस्तेमाल करके, सुरक्षित एपीआई प्रॉक्सी अनुरोध किए जा सकते हैं, और Edge उनकी पुष्टि ऐसे करेगा जैसे वे Edge से जनरेट हुए हों.
कुछ बैकग्राउंड
आम तौर पर, Apigee Edge, अक्षरों की रैंडम स्ट्रिंग बनाकर और एक टोकन जनरेट करता है नंबर. Apigee Edge, उस टोकन से जुड़ा होता है. अन्य डेटा, जैसे कि टोकन जारी किए जाने का समय, समयसीमा खत्म होने की तारीख, उन एपीआई प्रॉडक्ट की सूची जिनके लिए टोकन मान्य है, और स्कोप. इस सभी जानकारी को ऐसे जवाब में लौटाया जा सकता है जो OAuthV2 नीति के ज़रिए अपने-आप जनरेट होता है ऑपरेशन = generateAccessToken का इस्तेमाल करके कॉन्फ़िगर किया गया है. जवाब कुछ ऐसा दिखता है:
{ "issued_at": "1469735625687", "application_name": "06947a86-919e-4ca3-ac72-036723b18231", "scope": "urn://example.com/read", "status": "approved", "api_product_list": "[implicit-test]", "api_product_list_json": ["implicit-test"], "expires_in": "1799", //--in seconds "developer.email": "joe@weathersample.com", "token_type": "BearerToken", "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk", "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j", "organization_name": "wwitman", "refresh_token_expires_in": "0", //--in seconds "refresh_count": "0" }
access_token एट्रिब्यूट का मान असरदार तरीके से लुकअप कुंजी है
रिस्पॉन्स डेटा को हटा सकता है. ऐप्लिकेशन, Edge में होस्ट किए गए एपीआई प्रॉक्सी को ऐक्सेस करने का अनुरोध कर सकता है,
OAuthV2 के साथ - इसके साथ ही बियरर टोकन zBC90HhCGmGlaMBWeZAai2s3za5j
और Edge है
ऑपरेशन = VerifyAccessToken के साथ नीति - टोकन को खोजेगी और पूरी जानकारी हासिल करेगी,
और उस जानकारी का इस्तेमाल करके यह तय करें कि टोकन, अनुरोध किए गए एपीआई प्रॉक्सी के लिए मान्य है या नहीं.
इसे टोकन की पुष्टि करना कहते हैं. ऊपर दी गई सभी जानकारी में टोकन शामिल है. कॉन्टेंट बनाने
access_token वैल्यू सिर्फ़ उस जानकारी को देखने का तरीका है.
वहीं दूसरी ओर, यहां बताया गया तरीका अपनाकर, Edge को कॉन्फ़िगर किया जा सकता है ताकि इसकी access_token वैल्यू किसी बाहरी कंपनी से जनरेट की जा सके सेवा. बाकी सभी मेटाडेटा एक जैसा हो सकता है. उदाहरण के लिए, मान लें कि आपके पास एक सिस्टम है Apigee Edge का बाहरी वर्शन, जो "TOKEN-<16 रैंडम" फ़ॉर्म के टोकन जनरेट करता है नंबर>" को अपनाएं. ऐसे मामले में, Apigee Edge के पास सेव किया गया पूरा टोकन मेटाडेटा यह हो सकता है:
{ "issued_at": "1469735625687", "application_name": "06947a86-919e-4ca3-ac72-036723b18231", "scope": "urn://example.com/read", "status": "approved", "api_product_list": "[implicit-test]", "api_product_list_json": ["implicit-test"], "expires_in": "1799", //--in seconds "developer.email": "joe@weathersample.com", "token_type": "BearerToken", "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk", "access_token": "TOKEN-1092837373654221", "organization_name": "wwitman", "refresh_token_expires_in": "0", //--in seconds "refresh_count": "0" }
इस मामले में कोई ऐप्लिकेशन, Edge में होस्ट किए गए एपीआई प्रॉक्सी को अनुरोध भेज सकता है, जिसमें बियरर मौजूद होता है
टोकन TOKEN-1092837373654221
और Edge - OAuthV2 नीति के ज़रिए ऑपरेशन =
VerifyAccessToken - इसकी पुष्टि कर सकेगा. आप ऐसा ही आयात पैटर्न लागू कर सकते हैं:
ऑथराइज़ेशन कोड और रीफ़्रेश टोकन.
चलिए, क्लाइंट की पुष्टि करने के बारे में बात करते हैं क्रेडेंशियल
टोकन जनरेट करने के लिए एक ज़रूरी शर्त, अनुरोध करने वाले क्लाइंट की पुष्टि करना है. डिफ़ॉल्ट रूप से, Apigee Edge में OAuthV2/GenerateAccessToken नीति, क्लाइंट क्रेडेंशियल की साफ़ तौर पर पुष्टि करती है. आम तौर पर, OAuthV2 टोकन के अनुरोध में, client_id और client_secret को अनुमति देने वाला हेडर, जिसे एचटीटीपी बेसिक ऑथराइज़ेशन की मदद से कोड में बदला गया है (कोलन को जोड़कर बनाया गया, फिर base64 कोड में बदला गया. Apigee Edge की OAuthV2/generateAccessToken नीति उस हेडर को डिकोड करती है और Client_id देखता है और पुष्टि करता है कि पास किया गया client_secret उसके लिए मान्य है client_id. यह तब काम करता है, जब क्रेडेंशियल की जानकारी Apigee Edge के पास हो - दूसरे शब्दों में कहें, तो डेवलपर ऐप्लिकेशन, Apigee Edge में सेव होता है. इसमें एक क्रेडेंशियल होता है, जिसमें दिया गया client_id और client_secret.
अगर Apigee Edge से क्लाइंट क्रेडेंशियल की पुष्टि नहीं हो रही है, तो आपको इससे पहले कि आपका एपीआई प्रॉक्सी टोकन जनरेट करे, अपना एपीआई प्रॉक्सी से संपर्क करना है. आम तौर पर, ऐसा सर्विसकॉलआउट नीति के ज़रिए होता है आपके नेटवर्क के रिमोट एंडपॉइंट से कनेक्ट करता है.
सीधे तौर पर या किसी दूसरे तरीके से, आपको यह पक्का करना होगा कि एपीआई प्रॉक्सी जो टोकन जनरेट करता है, तो सबसे पहले क्लाइंट के क्रेडेंशियल की पुष्टि करता है. ध्यान रखें कि पुष्टि करने के लिए क्लाइंट, ऐक्सेस टोकन जनरेट करने से अलग है. दोनों के लिए, Apigee Edge को कॉन्फ़िगर किया जा सकता है, या इनमें से किसी एक का इस्तेमाल करने के लिए कहा जाता है.
अगर आपको Apigee Edge में OAuthV2/GenerateAccessToken नीति की मदद से क्लाइंट की पुष्टि करनी हो
एज स्टोर के लिए क्रेडेंशियल, <ExternalAuthorization>
एलिमेंट को इस पर सेट करें
false
या उसे पूरी तरह से हटा दें. अगर आपको किसी
बाहरी प्राधिकरण सेवा को क्लाइंट क्रेडेंशियल की स्पष्ट रूप से पुष्टि करने के लिए, सेट करें
true
के लिए <ExternalAuthorization>
.
हालांकि, हो सकता है कि Apigee Edge, क्लाइंट क्रेडेंशियल की पुष्टि न कर पाए, लेकिन यह अब भी client_id को Apigee Edge के ज़रिए जाना और मैनेज किया जाना है. Apigee Edge में हर access_token, चाहे इसे Apigee Edge से जनरेट किया जाता है या किसी बाहरी सिस्टम से जनरेट किया जाता है. इसके बाद, Apigee Edge में इंपोर्ट किया जाता है, किसी क्लाइंट ऐप्लिकेशन से जुड़ा होना चाहिए - जिसे client_id से दिखाया गया है. इसलिए, भले ही इस मामले में जहां Apigee Edge में OAuthV2/GenerateAccessToken नीति, इस बात की पुष्टि नहीं करेगी कि client_id और client_secret मेल खाता है, तो नीति यह सत्यापित करेगी कि client_id मान्य है, मौजूद है और नहीं है निरस्त किया गया है. इसलिए, सेटअप करने के लिए यह ज़रूरी है कि आप Client_id को Edge के ज़रिए इंपोर्ट करें. एडमिन एपीआई.
Apigee पर तीसरे पक्ष के OAuth की नीति का फ़्लो
Apigee Edge में तीसरे पक्ष के OAuth सिस्टम के टोकन का इस्तेमाल करने के लिए, ऐक्सेस जनरेट करने का फ़्लो टोकन में से किसी एक पैटर्न का पालन करना चाहिए.
कोई अन्य सोर्स क्लाइंट के क्रेडेंशियल की पुष्टि करना
- ServiceCallout का इस्तेमाल, इनबाउंड क्लाइंट क्रेडेंशियल की पुष्टि और बाहरी टोकन पाने के लिए किया जाता है.
- ExtractVariables या a JavaScript चरण से रिस्पॉन्स से बाहरी तौर पर जनरेट किया गया टोकन निकालें.
- इसके लिए AssignMessage
oauth_external_authorization_status
नाम का विशेष जाने-पहचाने वैरिएबल सेट करें. वैल्यू सही होनी चाहिए, ताकि यह पता चल सके कि क्लाइंट क्रेडेंशियल मान्य हैं. - OAuthV2/GenerateAccessToken
<ExternalAuthorization>
एलिमेंट कोtrue
पर सेट किया गया है. साथ ही, कम से कम एक एलिमेंट को सेट किया गया है<ExternalAccessToken>
,<ExternalRefreshToken>
या<ExternalAuthorizationCode>
.
आंतरिक क्लाइंट के क्रेडेंशियल की पुष्टि करना
- ServiceCallout बाहरी टोकन को हासिल करने के लिए.
- ExtractVariables या a JavaScript चरण से रिस्पॉन्स से बाहरी तौर पर जनरेट किया गया टोकन निकालें.
- OAuthV2/GenerateAccessToken
<ExternalAuthorization>
एलिमेंट कोfalse
पर सेट किया गया है. साथ ही, कम से कम एक एलिमेंट को सेट किया गया है<ExternalAccessToken>
,<ExternalRefreshToken>
या<ExternalAuthorizationCode>
.
फ़्लो और नीति कॉन्फ़िगरेशन के बारे में नोट
-
अगर आपको क्लाइंट क्रेडेंशियल की पुष्टि करने के लिए किसी बाहरी सिस्टम का इस्तेमाल करना है, तो ज़रूरी काम करने के लिए नीति का फ़्लो बनाया जा सकता है. आम तौर पर, सेवाकॉलआउट की नीति, बाहरी उपयोगकर्ताओं को बाहरी डोमेन से क्रेडेंशियल भेजने की अनुमति देती है पुष्टि करने की सेवा. पुष्टि करने वाली बाहरी सेवा आम तौर पर जवाब देगी और अगर क्रेडेंशियल मान्य हैं, तो एक ऐक्सेस टोकन भी होगा.
-
सेवाकॉलआउट के बाद, एपीआई प्रॉक्सी को मान्य होने की स्थिति, साथ ही साथ बाहरी रूप से जनरेट किया गया access_token और शायद refresh_token.
-
OAuthV2/GenerateAccessToken नीति में,
<StoreToken>
एलिमेंट सेट करेंtrue
पर सेट करें और<ExternalAuthorization>
एलिमेंट कोtrue
याfalse
.OAuthV2/GenerateAccessToken नीति के लागू होने पर, यह वैरिएबल को पढ़ता है
oauth_external_authorization_status
. अगर वैरिएबल सेट है और वैल्यू सही है, तो Apigee Edge, क्लाइंट क्रेडेंशियल की पुष्टि करने की कोशिश नहीं करता है. अगर वैरिएबल सेट नहीं है या वैल्यू सही नहीं है, तो Apigee Edge, क्लाइंट की पुष्टि करने की कोशिश करेगा क्रेडेंशियल डालें. -
OAuthV2 नीति के तीन एलिमेंट हैं, जिनकी मदद से बाहरी इंपोर्ट किया जाने वाला डेटा:
<ExternalAccessToken>
,<ExternalRefreshToken>
, और<ExternalAuthorizationCode>
. इनमें से हर एक एलिमेंट flow वैरिएबल भी शामिल है. Edge नीति उस वैरिएबल को पढ़ेगी जो बाहरी तरीके से जनरेट किया गया ऐक्सेस टोकन, रीफ़्रेश टोकन या ऑथराइज़ेशन कोड. यह आप पर निर्भर करता है बाहरी टोकन या कोड को सही जगह पर लागू करने के लिए, नीतियां और तर्क लागू करना वैरिएबल.उदाहरण के लिए, OAuthV2 नीति में नीचे दिया गया कॉन्फ़िगरेशन Edge को बताता है कि टोकन
external_token
नाम के कॉन्टेक्स्ट वैरिएबल में मौजूद होता है.<ExternalAccessToken>external_token</ExternalAccessToken>
आपको एक पिछला चरण भी सेट करना होगा, जो उस वैरिएबल को सेट करता हो.
-
oauth_external_authorization_status
वैरिएबल को सेट करने के बारे में, यह एक सामान्य इस वैरिएबल को सेट करने की तकनीक के साथ AssignMessage नीति का इस्तेमाल करके AssetVariable एलिमेंट की जानकारी दें, जैसे कि:<AssignMessage name="AssignMessage-SetVariable"> <DisplayName>Assign Message - Set Variable</DisplayName> <AssignVariable> <Name>oauth_external_authorization_status</Name> <Value>true</Value> </AssignVariable> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </AssignMessage>
याद रखें कि यह नीति ऑपरेशन = GenerateAccessToken.
OAuthV2 नीति का उदाहरण
OAuthV2 नीति
एक Apigee Edge ऐक्सेस टोकन जनरेट करता है, क्योंकि Edge
फ़्लो वैरिएबल external_access_token
में टोकन की वैल्यू.
<OAuthV2 name="OAuth-v20-Store-External-Token"> <ExternalAccessToken>external_access_token</ExternalAccessToken> <ExternalAuthorization>true</ExternalAuthorization> <Operation>GenerateAccessToken</Operation> <GenerateResponse enabled="true"> <Format>FORM_PARAM</Format> </GenerateResponse> <ReuseRefreshToken>false</ReuseRefreshToken> <StoreToken>true</StoreToken> <SupportedGrantTypes> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <ExpiresIn ref='flow.variable'>2400000</ExpiresIn> </OAuthV2>अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
आपके पास इस पैटर्न को तीसरे पक्ष के किसी OAuth2 की अनुमति के साथ लागू करने का विकल्प है सेवा.