Inhabertoken (JWT: RFC 7519), das von dem Identitätsanbieter (IdP) ausgestellt wurde, um die Identität eines Nutzers zu bestätigen.
| JSON-Darstellung | |
|---|---|
{ "aud": string, "email": string, "exp": string, "iat": string, "iss": string, "google_email": string, ... } |
|
| Felder | |
|---|---|
aud |
Die Zielgruppe, wie vom IdP identifiziert. Sollte mit der lokalen Konfiguration verglichen werden. |
email |
Die E-Mail-Adresse des Nutzers. |
exp |
Ablaufzeit. |
iat |
Ausstellungszeit. |
iss |
Der Tokenaussteller. Sollte mit der vertrauenswürdigen Gruppe von Authentifizierungsausstellern verglichen werden. |
google_email |
Ein optionaler Anspruch, der verwendet werden kann, wenn sich der E-Mail-Anspruch in diesem JWT von der E-Mail-ID des Google Workspace-Nutzers unterscheidet. Dieser Anspruch enthält die E-Mail-Identität des Google Workspace-Nutzers. |
... |
Ihr Key Access Control List Service (KACLS) kann alle anderen Ansprüche (Standort, benutzerdefinierter Anspruch usw.) verwenden, um den Perimeter zu bewerten. |
KACLS-Authentifizierungstoken für delegate
Das Authentifizierungstoken enthält ein JSON Web Token (JWT) (JWT: RFC 7519), das ein Inhaber-Authentifizierungstoken ist.
Manchmal kann sich ein Nutzer nicht direkt auf einem Client authentifizieren. In diesen Fällen kann der Nutzer den Zugriff auf eine bestimmte Ressource an diesen Client delegieren. Dies geschieht durch die Ausstellung eines neuen delegierten Authentifizierungstokens, das den Umfang des ursprünglichen Authentifizierungstokens einschränkt.
Das delegierte Authentifizierungstoken ähnelt dem normalen Authentifizierungstoken, enthält aber einen zusätzlichen Anspruch:
| Anspruch | |
|---|---|
delegated_to |
Eine Kennung für die Entität, an die die Authentifizierung delegiert werden soll. |
Der Anspruch resource_name im Authentifizierungstoken wird im Rahmen der Delegierung verwendet, um das Objekt zu identifizieren, das mit dem Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) verschlüsselt wurde und für das die Delegierung gilt.
Das Token wird vom Key Access Control List Service (KACLS) mit dem Aufruf Delegate ausgestellt. Dabei kann es sich entweder um selbstsignierte JWTs handeln, die vom KACLS validiert werden können, oder der KACLS kann über einen vertrauenswürdigen Aufruf einen anderen IdP verwenden.
Damit das delegierte Authentifizierungstoken als gültig betrachtet wird, muss für denselben Vorgang ein delegiertes Autorisierungstoken bereitgestellt werden. Das delegierte Autorisierungstoken ähnelt dem normalen Autorisierungstoken, enthält aber den zusätzlichen Anspruch delegated_to. Die Werte der Ansprüche delegated_to und resource_name müssen mit den Werten im delegierten Authentifizierungstoken übereinstimmen.
Wir empfehlen, für die delegierten Authentifizierungstokens eine Lebensdauer von 15 Minuten festzulegen, um eine mögliche Wiederverwendung im Falle eines Datenlecks zu vermeiden.
| JSON-Darstellung | |
|---|---|
{ "email": string, "iss": string, "aud": string, "exp": string, "iat": string, "google_email": string, "delegated_to": string, "resource_name": string ... } |
|
| Felder | |
|---|---|
email |
Die E-Mail-Adresse des Nutzers im UTF-8-Format. |
iss |
Der Tokenaussteller. Sollte mit der vertrauenswürdigen Gruppe von Authentifizierungsausstellern verglichen werden. |
aud |
Die Zielgruppe, wie vom IdP identifiziert. Sollte mit der lokalen Konfiguration verglichen werden. |
exp |
Ablaufzeit. Sollte geprüft werden. |
iat |
Ausstellungszeit. Sollte geprüft werden. |
delegated_to |
Eine Kennung für die Entität, an die die Authentifizierung delegiert werden soll. |
resource_name |
Eine Kennung für das Objekt, das mit dem DEK verschlüsselt wurde und für das die Delegierung gilt. |
... |
Der KACLS kann alle anderen Ansprüche (Standort, benutzerdefinierter Anspruch, usw.) verwenden, um den Perimeter zu bewerten. |
KACLS-Authentifizierungstoken für PrivilegedUnwrap
Inhabertoken (JWT: RFC 7519), das vom Identitätsanbieter (IdP) ausgestellt wurde, um die Identität eines Nutzers zu bestätigen.
Dieses Token wird nur für PrivilegedUnwrap verwendet. Wenn während PrivilegedUnwrap ein KACLS-JWT anstelle eines IdP-Authentifizierungstokens verwendet wird, muss der empfangende KACLS zuerst die JWKS des Ausstellers abrufen, dann die Tokensignatur überprüfen und erst dann die Ansprüche prüfen.
| JSON-Darstellung | |
|---|---|
{ "aud": string, "exp": string, "iat": string, "iss": string, "kacls_url": string, "resource_name": string ... } |
|
| Felder | |
|---|---|
aud |
Die Zielgruppe, wie vom IdP identifiziert. Für Vorgänge der clientseitigen Verschlüsselung von Google Drive
|
exp |
Ablaufzeit. |
iat |
Ausstellungszeit. |
iss |
Der Tokenaussteller. Sollte mit der vertrauenswürdigen Gruppe von
Authentifizierungsausstellern verglichen werden. Muss mit der |
kacls_url |
URL des aktuellen KACLS, auf dem die Daten entschlüsselt werden. |
resource_name |
Eine Kennung für das Objekt, das mit dem DEK verschlüsselt wurde. Maximale Größe: 128 Byte. |
... |
Ihr Key Access Control List Service (KACLS) kann alle anderen Ansprüche (Standort, benutzerdefinierter Anspruch usw.) verwenden, um den Perimeter zu bewerten. |