Skip to content

Latest commit

 

History

History
192 lines (166 loc) · 7.32 KB

token-claims-contextual-tuples.mdx

File metadata and controls

192 lines (166 loc) · 7.32 KB
sidebar_position slug description
9
/modeling/token-claims-contextual-tuples
Using identity token claims to define contextual relations

import { AuthzModelSnippetViewer, CardBox, CheckRequestViewer, DocumentationNotice, Playground, ProductConcept, ProductName, ProductNameFormat, RelatedSection, RelationshipTuplesViewer, UpdateProductNameInLinks, WriteRequestViewer, } from '@components/Docs';

Use Token Claims As Contextual Tuples

Contextual Tuples allow authorization checks that depend on dynamic or contextual relationships that have not been written to the store, enabling some Attribute Based Access Control (ABAC) use cases.

To enable more ABAC use-cases that rely on specific attributes and conditions, you can also use `s conditions.

Before You Start

To follow this guide, familiarize yourself with the following :

  • A : is a string defined in the type definition of an authorization model that defines the possibility of a relationship between an object of the same type as the type definition and a user in the system.
  • A : is a call to the check endpoint that returns whether the user has a certain relationship with an object.
  • A : a grouping consisting of a user, a relation and an object stored in

User Directories, Identity Tokens, And Relationships

User directories store user information that's accessed when making authorization decisions, like the group the user belongs to, their roles, or their department. The natural way to use those relationships in a Relationship-Based Access Control system like is to create tuples for each relation. However, implementing a synchronization mechanism to keep the user directory data up to date with tuples in the store can be challenging.

When applications implement authentication using an OIDC authorization service, they receive an ID Token or an Access token, with certain claims that can be customized based on the application's needs. Instead of writing tuples to the , you can use the content of the token in Contextual Tuples to make authorization checks, understanding that, if those relationships change while the token has not expired, users will still get access to the resources the content of the token entitled them to.

Example

In this example, the application uses the following authorization model, in which documents can be viewed by members of a group:

<AuthzModelSnippetViewer configuration={{ "schema_version":"1.1", "type_definitions": [ { "type":"user" }, { "metadata": { "relations": { "member": { "directly_related_user_types": [ { "type":"user" } ] } } }, "relations": { "member": { "this": {} } }, "type":"group" }, { "metadata": { "relations": { "viewer": { "directly_related_user_types": [ { "relation":"member", "type":"group" } ] } } }, "relations": { "viewer": { "this": {} } }, "type":"document" } ] }} />

When a group is added as a viewer of a document, the application writes tuples like those below:

<WriteRequestViewer relationshipTuples={[ { "_description": "Members of the marketing group can view the product-launch document", "user": "group:marketing#member", "relation": "viewer", "object": "document:product-launch" }, { "_description": "Members of the everyone group can view the welcome document", "user": "group:everyone#member", "relation": "viewer", "object": "document:welcome" } ]} />

Let's assume that the Access Token the application receives has a list of the groups the user belongs to:

{
  "iss": "https://id.company.com",
  "sub": "6b0b14af-59dc-4ff3-a46f-ad351f428726",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516239022,
  "azp" : "yz54KAoW1KGFAUU982CEUqZgxGIdrpgg",
  "groups": ["marketing", "everyone"]
}

When making a authorization check, the application uses the groups claim in the token and adds contextual tuple for each group, indicating that the user is a member of that group:

<CheckRequestViewer user={'user:6b0b14af-59dc-4ff3-a46f-ad351f428726'} relation={'viewer'} object={'document:product-launch'} allowed={true} contextualTuples={[ { _description: 'user 6b0b14af-59dc-4ff3-a46f-ad351f428726 is a member of the marketing group', user: 'user:6b0b14af-59dc-4ff3-a46f-ad351f428726', relation: 'member', object: 'group:marketing', }, { _description: 'user 6b0b14af-59dc-4ff3-a46f-ad351f428726 is a member of the everyone group', user: 'user:6b0b14af-59dc-4ff3-a46f-ad351f428726', relation: 'member', object: 'group:everyone', }, ]} />

The authorization check returns allowed = true, as there's a stored tuple saying that members of the marketing group are viewers of the product-launch document, and there's a contextual tuple indicating that the user is a member of the marketing group.

:::caution Warning Contextual tuples:

  • Do not persist in the store.

  • Are only supported on the and . They are not supported on read, expand, or other endpoints.

  • If you use the to build a permission aware search index, it may be difficult to account for contextual tuples. :::

Related Sections

<RelatedSection description="Check the following sections for more on how user contextual tuples can be used." relatedLinks={[ { title: 'Contextual and Time-Based Authorization', description: 'Learn how to authorize access that depends on dynamic or contextual criteria.', link: './contextual-time-based-authorization', id: './contextual-time-based-authorization.mdx', }, { title: 'Authorization Through Organization Context', description: 'Learn to model and authorize when a user belongs to multiple organizations.', link: './organization-context-authorization', id: './organization-context-authorization.mdx', }, { title: 'Conditions', description: 'Learn to model requiring dynamic attributes.', link: './conditions', id: './conditions.mdx', }, { title: '{ProductName} API', description: 'Details on the Check API in the {ProductName} reference guide.', link: '/api/service#Relationship%20Queries/Check', } ]} />