तरीका: 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 को ऐक्सेस करने की अनुमति है. ज़्यादा जानकारी के लिए, ऑथराइज़ेशन टोकन देखें.
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 दावे शामिल होते हैं. इस टोकन का इस्तेमाल बाद में, Wrap और Unwrap तरीकों को कॉल करने के दौरान पुष्टि करने के लिए किया जा सकता है. गड़बड़ी होने पर, स्ट्रक्चर्ड फ़ॉर्मैट में जवाब देना चाहिए.

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

string

यह पुष्टि करने के लिए डेलिगेट किया गया JWT है. इसकी मदद से, ओरिजनल पुष्टि करने वाले JWT में बताए गए उपयोगकर्ता को resource_name ऐक्सेस करने की अनुमति मिलती है. ज़्यादा जानकारी के लिए, 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...}"
}