שיטה: הענקת גישה לאדם אחר
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
הקריאה הזו מחזירה אסימון אינטרנט חדש מסוג JSON (JWT) לאימות, שמאפשר לישות לגשת למשאב שצוין בשם המשתמש שאומת ב-JWT המקורי לאימות. היא משמשת להענקת גישה מוגבלת לעטיפה או לפרימה לישות אחרת, כשהישות הזו צריכה לפעול בשם המשתמש.
בקשת HTTP
POST https://<base_url>/delegate
מחליפים את <base_url> בכתובת ה-URL של שירות רשימת המפתחות של בקרת הגישה (KACLS).
פרמטרים של נתיב
ללא.
גוף הבקשה
גוף הבקשה מכיל ייצוג JSON של הבקשה:
| ייצוג ב-JSON |
{
"authentication": string,
"authorization": string,
"reason": string
}
|
| שדות |
authentication |
string
JWT שהונפק על ידי צד שלישי, שבו מצוין מי המשתמש. פרטים נוספים זמינים בקטע בנושא אימות.
|
authorization |
string
JWT עם הצהרות delegated_to ו-resource_name שמאשרות שהישות שמזוהה על ידי ההצהרה delegated_to מורשית לגשת אל resource_name בשם המשתמש. מידע נוסף זמין במאמר אסימוני הרשאה.
|
reason |
string (UTF-8)
מחרוזת JSON של העברת נתונים שמספקת הקשר נוסף לגבי הפעולה. צריך לבצע סניטציה ל-JSON שסופק לפני שמציגים אותו. גודל מקסימלי: 1KB.
|
שלבי העיבוד הנדרשים
ה-KACLS חייב לבצע לפחות את השלבים הבאים:
- צריך לאמת את טוקני ההרשאה והאימות. מידע נוסף זמין במאמרים בנושא אסימוני הרשאה ואסימוני אימות.
- בודקים שאסימוני ההרשאה והאימות הם של אותו משתמש.
מידע נוסף זמין במאמר בנושא הצפנה ופענוח של נתונים.
- בודקים שהצהרת
kacls_url באסימון ההרשאה תואמת לכתובת ה-URL הנוכחית של KACLS. כך אפשר לזהות שרתי פוטנציאליים של תקיפת 'אדם באמצע' שהוגדרו על ידי משתמשים פנימיים או אדמינים של דומיין סורר.
- אם התביעה
kacls_owner_domain קיימת באסימון ההרשאה, צריך לוודא שהערך תואם לדומיין Google Workspace של הבעלים של KACLS. כך אפשר למנוע ממשתמשים לא מורשים לרשום את רשימת בקרת הגישה שלכם ב-Google.
- רישום הפעולה ביומן, כולל המשתמש שיזם אותה,
delegated_to,
resource_name והסיבה שהועברה בבקשה.
- יוצרים, חותמים ומחזירים טוקן JWT שמכיל הצהרות
delegated_to ו-resource_name מטוקן ההרשאה.
ה-KACLS יכול לבצע בדיקות אבטחה נוספות בחינם, כולל בדיקות שמבוססות על טענות JWT.
גוף התשובה
אם הפעולה בוצעה ללא שגיאות, השיטה הזו מחזירה JWT לאימות שמכיל טענות delegated_to ו-resource_name. אפשר להשתמש באסימון הזה מאוחר יותר לאימות בשיחות לשיטות Wrap ו-Unwrap. במקרה של שגיאה, צריך להחזיר תשובה עם שגיאה מובנית.
| ייצוג ב-JSON |
{
"delegated_authentication": string
}
|
| שדות |
delegated_authentication |
string
אסימון JWT של אימות עם הרשאת גישה, שתקף לגישה אל resource_name על ידי המשתמש שמוזכר באסימון ה-JWT המקורי של האימות. מידע נוסף זמין במאמר אסימון אימות של KACLS ל-delegate.
|
דוגמה
בקשה
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...}"
}
אלא אם צוין אחרת, התוכן של דף זה הוא ברישיון Creative Commons Attribution 4.0 ודוגמאות הקוד הן ברישיון Apache 2.0. לפרטים, ניתן לעיין במדיניות האתר Google Developers. Java הוא סימן מסחרי רשום של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-26 (שעון UTC).
[null,null,["עדכון אחרון: 2025-07-26 (שעון UTC)."],[],[],null,["# Method: delegate\n\nThis call returns a new authentication JSON Web Token (JWT) that allows\nan entity to access a specified resource on behalf of the user\nauthenticated in the original authentication JWT. It is used to delegate\nscoped access to [wrap](/workspace/cse/reference/wrap) or\n[unwrap](/workspace/cse/reference/unwrap) to another entity when that\nentity needs to act on behalf of the user.\n\n### HTTP request\n\n`POST https://\u003cbase_url\u003e/delegate`\n\nReplace `\u003cbase_url\u003e` with the Key Access Control List Service (KACLS) URL.\n\n### Path parameters\n\nNone.\n\n### Request body\n\nThe request body contains a JSON representation of the request:\n\n| JSON representation ||\n|---------------------------------------------------------------------------------|---|\n| ``` { \"authentication\": string, \"authorization\": string, \"reason\": string } ``` |\n\n| Fields ||\n|------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `authentication` | `string` A JWT issued by a third-party asserting who the user is. See the authentication section for details. |\n| `authorization` | `string` A JWT with `delegated_to` and `resource_name` claims asserting that the entity identified by `delegated_to` claim is allowed to access `resource_name` on behalf of the user. For more information, see [Authorization Tokens](/workspace/cse/reference/authorization-tokens). |\n| `reason` | `string (UTF-8)` A passthrough JSON string providing additional context about the operation. The JSON provided should be sanitized before being displayed. Max size: 1 KB. |\n\n### Required processing steps\n\nThe KACLS must perform at least these steps:\n\n- Validate both authorization and authentication tokens. For more information, see [Authorization Tokens](/workspace/cse/reference/authorization-tokens) and [Authentication Tokens](/workspace/cse/reference/authentication-tokens).\n- Check that authorization and authentication tokens are for the same user. For more information, see [Encrypt and decrypt data](/workspace/cse/guides/encrypt-and-decrypt-data).\n- Check that the `kacls_url` claim in the authorization token matches the current KACLS URL. This allows detection of potential man-in-the-middle servers configured by insiders or rogue domain admins.\n- If the `kacls_owner_domain` claim exists in the authorization token, check that the value matches the KACLS owner's Google Workspace domain. This helps prevent unauthorized users from registering your KACLS with Google.\n- Log the operation, including the user originating it, the `delegated_to`, the `resource_name`, and the reason passed in the request.\n- Generate, sign, and return a JWT token containing `delegated_to` and `resource_name` claims from the authorization token.\n\nThe KACLS is free to perform additional security checks, including JWT claim\nbased ones.\n\n### Response body\n\nIf successful, this method returns an authentication JWT containing\n`delegated_to` and `resource_name` claims. This token can later be used for\nauthentication in calls to the Wrap and Unwrap methods. In case of an error, a\n[structured error reply](/workspace/cse/reference/structured-errors)\nshould be returned.\n\n| JSON representation ||\n|------------------------------------------------|---|\n| ``` { \"delegated_authentication\": string } ``` |\n\n| Fields ||\n|----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `delegated_authentication` | `string` A delegated authentication JWT valid for accessing `resource_name` by the user mentioned in the original authentication JWT. For more information, see [KACLS authentication token for `delegate`](/workspace/cse/reference/authentication-tokens#kacls_authentication_token_for_delegate). |\n\n### Example\n\n#### Request\n\n POST https://mykacls.example.com/v1/delegate\n {\n \"authentication\": \"eyJhbGciOi...\",\n \"authorization\": \"eyJhbGciOi...delegated_to\\\":\\\"other_entity_id\\\",\\\"resource_name\\\":\\\"meeting_id\\\"...}\",\n \"reason\": \"{client:'meet' op:'delegate_access'}\"\n }\n\n#### Response\n\n {\n \"delegated_authentication\": \"eyJhbGciOi...delegated_to_from_authz_token...resource_name_from_authz_token...}\"\n }"]]
