तरीका: delegate

यह कॉल, पुष्टि करने वाला नया JSON Web Token (JWT) दिखाता है. इससे कोई इकाई, उपयोगकर्ता की ओर से किसी तय किए गए संसाधन को ऐक्सेस कर सकती है. इस उपयोगकर्ता की पुष्टि, पुष्टि करने वाले ओरिजनल JWT में की गई है. इसका इस्तेमाल, किसी दूसरी इकाई को स्कोप किए गए ऐक्सेस को सौंपने के लिए किया जाता है. ऐसा तब किया जाता है, जब उस इकाई को उपयोगकर्ता की ओर से रैप या अनरैप करना होता है.

एचटीटीपी अनुरोध

POST https://<base_url>/delegate

<base_url> की जगह, कुंजी ऐक्सेस कंट्रोल लिस्ट सर्विस (केएसीएलएस) का यूआरएल डालें.

पाथ पैरामीटर

कोई नहीं.

अनुरोध का मुख्य भाग

अनुरोध के मुख्य हिस्से में, अनुरोध का JSON फ़ॉर्मैट शामिल होता है:

JSON के काेड में दिखाना 
{
  "authentication": string,
  "authorization": string,
  "reason": string
}
फ़ील्ड
authentication

string

यह तीसरे पक्ष की ओर से जारी किया गया JWT है. इससे यह पता चलता है कि उपयोगकर्ता कौन है. ज़्यादा जानकारी के लिए, पुष्टि करने से जुड़ा सेक्शन देखें.
authorization

string

यह delegated_to और resource_name दावों वाला JWT है. इससे यह पुष्टि होती है कि delegated_to दावे से पहचानी गई इकाई को उपयोगकर्ता की ओर से resource_name को ऐक्सेस करने की अनुमति है. ज़्यादा जानकारी के लिए, Authorization Tokens देखें.
reason

string (UTF-8)

यह एक पासथ्रू JSON स्ट्रिंग है. इससे ऑपरेशन के बारे में अतिरिक्त जानकारी मिलती है. दिखाने से पहले, दिए गए JSON को सैनिटाइज़ किया जाना चाहिए. ज़्यादा से ज़्यादा साइज़: 1 केबी.

प्रोसेसिंग के लिए ज़रूरी चरण

KACLS को कम से कम ये चरण पूरे करने होंगे:

  • अनुमति और पुष्टि करने वाले, दोनों टोकन की पुष्टि करें. ज़्यादा जानकारी के लिए, ऑथराइज़ेशन टोकन और पुष्टि करने वाले टोकन देखें.
  • देखें कि अनुमति और पुष्टि करने वाले टोकन, एक ही उपयोगकर्ता के लिए हों. ज़्यादा जानकारी के लिए, डेटा को एन्क्रिप्ट (सुरक्षित) और डिक्रिप्ट (सुरक्षित तरीके से बदलना) करना लेख पढ़ें.
  • जांच करें कि अनुमति देने वाले टोकन में मौजूद kacls_url दावा, KACLS के मौजूदा यूआरएल से मेल खाता हो. इससे, अंदरूनी लोगों या धोखेबाज़ डोमेन एडमिन की ओर से कॉन्फ़िगर किए गए संभावित मैन-इन-द-मिडल सर्वर का पता लगाया जा सकता है.
  • अगर ऑथराइज़ेशन टोकन में kacls_owner_domain दावा मौजूद है, तो जांच करें कि वैल्यू, KACLS के मालिक के Google Workspace डोमेन से मेल खाती हो. इससे, बिना अनुमति वाले लोगों को Google के साथ KACLS रजिस्टर करने से रोकने में मदद मिलती है.
  • कार्रवाई को लॉग करें. इसमें कार्रवाई करने वाला उपयोगकर्ता, delegated_to, resource_name, और अनुरोध में दी गई वजह शामिल है.
  • अनुमति टोकन से delegated_to और resource_name दावे वाला JWT टोकन जनरेट करता है, उस पर हस्ताक्षर करता है, और उसे वापस भेजता है.

KACLS, सुरक्षा से जुड़ी अतिरिक्त जांचें बिना किसी शुल्क के कर सकता है. इनमें JWT के दावे पर आधारित जांचें भी शामिल हैं.

जवाब का मुख्य भाग

अगर यह तरीका काम करता है, तो यह पुष्टि करने वाला JWT दिखाता है. इसमें delegated_to और resource_name दावे शामिल होते हैं. इस टोकन का इस्तेमाल बाद में, रैप और अनरैप करने के तरीकों के लिए कॉल में पुष्टि करने के लिए किया जा सकता है. गड़बड़ी होने पर, स्ट्रक्चर्ड फ़ॉर्मैट में गड़बड़ी का जवाब दिया जाना चाहिए.

JSON के काेड में दिखाना 
{
  "delegated_authentication": string
}
फ़ील्ड
delegated_authentication

string

यह पुष्टि करने के लिए डेलिगेट किया गया JWT है. इसका इस्तेमाल, resource_name को ऐक्सेस करने के लिए किया जा सकता है. इसे मूल पुष्टि करने वाले JWT में बताए गए उपयोगकर्ता के लिए मान्य किया गया है. ज़्यादा जानकारी के लिए, delegate के लिए KACLS पुष्टि करने वाला टोकन देखें.

उदाहरण

अनुरोध

POST https://mykacls.example.com/v1/delegate
{
  "authentication": "eyJhbGciOi...",
  "authorization": "eyJhbGciOi...delegated_to\":\"other_entity_id\",\"resource_name\":\"meeting_id\"...}",
  "reason": "{client:'meet' op:'delegate_access'}"
}

जवाब

{
  "delegated_authentication": "eyJhbGciOi...delegated_to_from_authz_token...resource_name_from_authz_token...}"
}