পদ্ধতি: প্রতিনিধি

এই কলটি একটি নতুন প্রমাণীকরণ JSON ওয়েব টোকেন (JWT) প্রদান করে যা একটি সত্তাকে মূল প্রমাণীকরণ JWT-তে প্রমাণীকরণকৃত ব্যবহারকারীর পক্ষ থেকে একটি নির্দিষ্ট রিসোর্স অ্যাক্সেস করার অনুমতি দেয়। এটি অন্য সত্তাকে মোড়ানো বা আনর্যাপ করার জন্য স্কোপড অ্যাক্সেস অর্পণ করতে ব্যবহৃত হয় যখন সেই সত্তাকে ব্যবহারকারীর পক্ষ থেকে কাজ করার প্রয়োজন হয়।

HTTP অনুরোধ

POST https://<base_url>/delegate

<base_url> কে কী অ্যাক্সেস কন্ট্রোল লিস্ট সার্ভিস (KACLS) 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 প্রদর্শনের আগে স্যানিটাইজ করা উচিত। সর্বোচ্চ আকার: ১ KB।

প্রয়োজনীয় প্রক্রিয়াকরণ পদক্ষেপ

KACLS-কে কমপক্ষে এই ধাপগুলি সম্পাদন করতে হবে:

• অনুমোদন এবং প্রমাণীকরণ টোকেন উভয়ই যাচাই করুন। আরও তথ্যের জন্য, অনুমোদন টোকেন এবং প্রমাণীকরণ টোকেন দেখুন।
• অনুমোদন এবং প্রমাণীকরণ টোকেন একই ব্যবহারকারীর জন্য কিনা তা পরীক্ষা করুন। আরও তথ্যের জন্য, ডেটা এনক্রিপ্ট এবং ডিক্রিপ্ট দেখুন।
• অনুমোদন টোকেনে kacls_url দাবিটি বর্তমান KACLS URL এর সাথে মেলে কিনা তা পরীক্ষা করুন। এটি অভ্যন্তরীণ ব্যক্তি বা দুর্বৃত্ত ডোমেন প্রশাসকদের দ্বারা কনফিগার করা সম্ভাব্য ম্যান-ইন-দ্য-মিডল সার্ভারগুলি সনাক্ত করার অনুমতি দেয়।
• যদি অনুমোদন টোকেনে kacls_owner_domain দাবিটি বিদ্যমান থাকে, তাহলে পরীক্ষা করে দেখুন যে মানটি KACLS মালিকের Google Workspace ডোমেনের সাথে মেলে কিনা। এটি অননুমোদিত ব্যবহারকারীদের Google-এ আপনার KACLS নিবন্ধন করা থেকে বিরত রাখতে সাহায্য করে।
• অপারেশনটি লগ করুন, যার মধ্যে এটি তৈরিকারী ব্যবহারকারী, delegated_to , resource_name এবং অনুরোধে পাস করা কারণ অন্তর্ভুক্ত রয়েছে।
• অনুমোদন টোকেন থেকে delegated_to এবং resource_name দাবি সম্বলিত একটি JWT টোকেন তৈরি করুন, স্বাক্ষর করুন এবং ফেরত দিন।

KACLS অতিরিক্ত নিরাপত্তা পরীক্ষা করতে পারে, যার মধ্যে JWT দাবি ভিত্তিক পরীক্ষাও অন্তর্ভুক্ত।

প্রতিক্রিয়া মূল অংশ

যদি সফল হয়, তাহলে এই পদ্ধতিটি delegated_to এবং resource_name দাবি সম্বলিত একটি প্রমাণীকরণ JWT ফেরত পাঠাবে। এই টোকেনটি পরবর্তীতে Wrap এবং Unwrap পদ্ধতিতে কল করার সময় প্রমাণীকরণের জন্য ব্যবহার করা যেতে পারে। কোনও ত্রুটির ক্ষেত্রে, একটি কাঠামোগত ত্রুটির উত্তর ফেরত পাঠানো উচিত।

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...}"
}