Types et actions¶

Cette page sert à la consultation : à quoi ressemble une règle, quels types d'éléments une règle peut nommer et ce que signifie chaque action sur chaque type. Ce que sont les règles et les rôles figure dans Rôles et accès.

Une règle¶

{"id": "own-department", "effect": "permit", "kind": "membership",
 "actions": ["see", "write"],
 "match": {"labels": {"office": "utrecht"}},
 "when": [{"atom": "label_among", "label": "department", "attribute": "department"}]}

Une condition dans when est l'une de ces trois :

Les attributs qu'une condition peut lire sont role (le nom d'un rôle intégré ou l'identifiant rol_... d'un rôle propre), group (l'identifiant grp_... d'un groupe) et tout attribut que l'organisation ou une organisation au-dessus a défini. OS refuse une condition sur un autre attribut.

Comment OS décide¶

• Rien n'est permis sans un permit qui s'applique ; un forbid qui s'applique refuse toujours. L'ordre n'a pas d'importance.
• Une règle s'applique si tout son match convient à l'élément et tout son when à la personne. Il n'y a ni « ou » ni « non » : deux valeurs possibles font deux règles.
• Les étiquettes et les attributs sont des ensembles de valeurs. Un élément sans l'étiquette ne correspond à aucun test sur cette étiquette.
• Aucune action n'en inclut une autre. OS demande d'abord see ; ce que la personne n'a pas le droit de voir n'existe pas pour elle (404).
• Créer quelque chose est un write, décidé sur les étiquettes de la requête. Modifier des étiquettes est décidé sur les anciennes et sur les nouvelles étiquettes.

Limites et restrictions¶

OS refuse en outre :

• un forbid sur organisation, membership, invitation, group, role, rule ou attribute : sur la gestion, vous n'écrivez que ce qui est permis ;
• une règle sur placement hors de l'organisation du sommet ;
• un attribute_has avec une valeur hors de la liste fixe de l'attribut, même si une organisation au-dessus l'a défini ;
• une condition sur un attribut que personne n'a défini ;
• une règle sur un type d'OS avec une action que le type ne connaît pas : chaque type n'accepte que les actions de sa ligne, si bien que, par exemple, use sur group ou membership n'est pas possible ;
• une règle sur les fonctions d'IA avec une partie que le type n'accepte pas (ci-dessous) ;
• dans un rôle propre : une règle sur router, egress_host, artifact_download, share_link ou memory_write.

Chacun de ces refus est un 422 à l'écriture ; rien ne change.

Une règle qui autorise ce qui ne fait pas partie du service de l'organisation, OS la refuse avec 403 (This is not part of your organisation's service.) : dans un rôle propre, dans le document de règles, et si vous donnez un rôle propre ou un groupe avec un tel rôle. Un rôle intégré se donne toujours ; le service ne fait que le réduire.

Dans le service¶

Une offre ou une exception nomme des types avec leurs actions, comme une règle, mais sans match ni when. Ces types font partie de chaque service et d'aucune offre : organisation, membership, invitation, group, role, rule, attribute, audit_event, service, webhook, event, export et notification_channel, et en plus placement et service_plan, que seul Artific gère. OS refuse avec 422 une offre ou une exception qui nomme l'un de ces types. Tout autre type ne fait partie du service que si une offre ou une exception le donne, comme les types de la connexion de l'entreprise, domain et sign_in.

Un élément ne nomme que des actions que le type connaît : pour les types d'OS celles de sa ligne, pour ceux des fonctions d'IA celles de leur tableau. Ainsi, thread n'accepte pas use. Les types sans actions (router, egress_host, artifact_download, share_link, memory_write) font entièrement partie du service ou pas du tout : un élément à leur sujet ne nomme pas actions. Sinon OS refuse l'offre ou l'exception avec 422.

Les types d'OS¶

Un type n'accepte que les actions de sa ligne : service seulement see et write, et organisation, membership, invitation, group, domain et sign_in pas de use. OS refuse avec 422 une règle, une offre ou une exception qui nomme une autre action. Une règle sans actions vaut pour les actions que le type connaît, et allowed_actions n'en nomme jamais d'autre.

placement et service_plan, OS ne les décide que pour qui agit depuis l'organisation du sommet. Un write sur service, OS le décide dans l'organisation au-dessus, pour qui y a org-admin avec la portée descendants (comment).

Ce que match lit sur un élément d'OS :

Les types des fonctions d'IA¶

Ces types concernent ce que les membres font dans les fonctions d'IA. Ils figurent dans CoreAccessKind.

Un type sans actions ne connaît pas actions : la règle concerne le type dans son ensemble.

Tous les types n'acceptent pas toutes les parties d'une règle. OS refuse avec 422, quand vous l'écrivez, une règle avec une partie que le type n'accepte pas ou avec une action qu'il ne connaît pas :

• Les lignes (thread, memory_record, knowledge_source, stored_file, datastore_record) n'ont pas de nom, donc pas de match.names. L'étiquette subject est qui a créé la ligne ; un subject vide ("") est une ligne partagée. Dans les fonctions d'IA, vous ne lisez l'étiquette subject que sur les lignes.
• file et datastore ne portent pas d'étiquettes, donc pas de match.labels, et comme condition seulement attribute_has.
• Pour toute l'organisation (router, egress_host, artifact_download, share_link, memory_write) : pas de condition sur la personne (when), et donc seulement dans le document de règles, jamais dans un rôle (comment). Elles n'acceptent pas d'étiquettes ; egress_host accepte match.names pour les adresses. Les routeurs de modèles et les téléchargements sont accessibles par défaut à chaque membre ; l'écriture dans la mémoire et le partage par un lien ne le sont à personne tant que le document de règles ne les autorise pas.