Partage

​

Objets et méthodes

​

Le modèle de droits

• Écrits par le propriétaire sur l’objet collection ; chaque changement de droit produit une ShareNotification pour le bénéficiaire et un changement enregistré pour la resynchronisation.
• Exercés par l’indirection shared: : un bénéficiaire adresse les données du propriétaire avec l’identifiant de compte accordé dans le slot accountId JMAP standard ; l’objet accounts de la session liste ce qui est joignable. Les capacités se résolvent sur l’appelant authentifié, la résidence des données sur le propriétaire : l’usurpation n’est pas représentable dans la forme de la requête.
• Fermés par défaut. Le dispatch des comptes partagés refuse par défaut ; une erreur de recherche de droits refuse plutôt que d’accorder.
• Un appel composé est admis pour lui-même. Une méthode qui en exécute une autre en son sein (le /get derrière les fetchProperties de Core/queryStream, les patchs de push, les reports d’alerte) fait passer à cette méthode interne la garde des comptes partagés et son admission propre, exactement comme si le client l’avait envoyée : hériter du contexte de l’appel extérieur, ce n’est pas hériter de son admission. Le bénéficiaire d’un seul dossier partagé lisait les règles ou les contacts du propriétaire par Core/queryStream ; le refus interne revient maintenant en forbidden. Les patchs de push ne servent plus Thread/get, VacationResponse/get, EmailSubmission/get ni CalendarEventNotification/get à un bénéficiaire, qui reçoit à la place un StateChange sans contenu. Chaque appel composé laisse aussi sa propre ligne dans le journal des accès aux données, rangée sous le propriétaire avec le bénéficiaire pour acteur ; dans une organisation en mode strict, une réponse dont la ligne ne peut pas être écrite est retenue (serverFail).
• Un flux de requête reste sur son compte. Chaque page d’un Core/queryStream ouvert sur shared:<owner>, cadencé par le client ou poussé par le serveur, vient de ce compte sous la même admission que la première : un flux poussé servait la page 1 depuis le propriétaire et les suivantes depuis le compte du bénéficiaire. Le curseur porte le compte où il a été ouvert et il est refusé en invalidArguments sur un autre ; un droit retiré pendant le flux l’arrête à la page suivante par streamFailed, qui nomme l’erreur.

​

Les octrois de compte, une collection entière

• Chaque objet de la collection, ceux créés après l’octroi compris : chaque dossier, agenda, liste de tâches, carnet de notes, le Drive entier. readOnly lit ; readWrite lit, écrit et détruit les éléments, chaque destruction inscrite dans la chaîne d’audit du propriétaire avec l’octroi, et ne partage, n’administre, n’envoie de courrier ni de message d’agenda (une écriture que seul l’octroi admet et qui enverrait une invitation est refusée). Une ligne au niveau admin, écrite hors du verbe, s’applique comme readWrite, jamais plus.
• En JMAP seulement. IMAP, CalDAV et CardDAV n’ouvrent aucun objet sur un octroi de compte ; les téléchargements de blobs, les vignettes et les envois suivent l’admission JMAP du type.
• Jamais Contact. JMAP ne sert aucun contact sur un compte partagé, donc un octroi de contacts annoncerait un accès qui n’ouvre rien : account grant --collection Contact est refusé et dit pourquoi. Une équipe partage un carnet d’adresses par un annuaire de tenant.
• Ses états lui appartiennent. Chaque état servi sous un octroi porte l’empreinte de l’octroi (réponses des méthodes, appels composés, WebSocket, EventSource et patchs de push) : un état obtenu avant l’octroi, sous un autre octroi ou à un autre niveau répond cannotCalculateChanges, et le client se resynchronise au lieu de lire un delta calculé pour d’autres droits. Sans octroi, les états restent identiques à l’octet près.

​

Les équipes et leur adresse

​

Sémantique d’annuaire à connaître

• Les types de principals sont honnêtes. Le principal d’un compte d’équipe partagé est type: "other" (non connectable), jamais individual : les sélecteurs de personnes peuvent se fier au type.
• Les bénéficiaires doivent être adossés à un humain, ou être un groupe. Un droit accordé à un principal adossé à un compte non connectable (le compte partagé d’une équipe, une ressource, un lieu) est rejeté à l’écriture sur tous les domaines ; un groupe est la seule exception, puisqu’un droit keyé sur un groupe résout vers ses membres au contrôle d’accès, et l’appartenance est réservée à l’administrateur pour exactement cette raison.
• Détruire un principal purge ses droits. Un destroy de Principal/set retire les clés du bénéficiaire de chaque carte shareWith (pas d’entrées d’ACL pendantes) et avertit ou s’interrompt s’il laisserait un drive partagé sans gardien éligible.
• L’effacement laisse des pierres tombales. Le principal d’une personne effacée est nettoyé de ses données personnelles mais conservé comme ancre de graphe, et un principal en pierre tombale est refusé comme nouveau bénéficiaire (conformité).
• Un compte gelé garde les mandats de l’organisation, pas les siens. Un droit porte qui l’a écrit : celui que le propriétaire a écrit est un mandat que le compte a donné, suspendu tant que le compte est gelé (role: disabled) et rétabli avec lui ; celui que l’opérateur a écrit au nom du propriétaire (account offboard --grant-mailbox-to, account grant, ou les clés de départ de Principal/setAdmin, voir l’API d’administration) est la décision de l’organisation et reste. Un droit sans auteur se lit comme celui du propriétaire, le sens fermé sur échec. Le droit d’un départ porte une expiration obligatoire, à un an au plus ; account grant --until est facultatif, et refusé vers un compte de service déclaré (service: true dans l’objet de capacité de compte, v2:account, des capabilities du principal), un connecteur qui ne part jamais (multi-tenancy).
• Les entités se déclarent, elles ne se déduisent pas. La profileCard d’une personne peut nommer son employeur dans organizations par référence à un groupe (l’identifiant du groupe sous oximail.ch:principalId) ; le nom se lit sur le groupe à chaque fois, si bien que le renommer corrige toutes les cartes. Seul un groupe qu’un administrateur de locataire a marqué isEntity: true peut être cité : Principal/set prend la marque à la création et à la mise à jour, sur un groupe seulement (invalidProperties sinon, forbidden pour un non-administrateur), et une carte qui cite un groupe non marqué est refusée en nommant le groupe. Principal/get sert toujours isEntity, et sur un groupe cardReferenceCount, le nombre de cartes qui le citent, pour qu’un client le sache avant un renommage ou une destruction ; retirer la marque d’une entité que des cartes citent encore, ou la détruire, est forbidden avec le nom et le nombre. Principal/query {filter: {isEntity: true}} alimente le sélecteur d’employeur (false : tout sauf les entités). Le côté console est sur la page multi-tenancy.
• Détruire un groupe libère son compte partagé, son adresse réservée et son siège, comme détruire une ressource ou un lieu le faisait déjà.
• Un compte de service agissant sous shared:<propriétaire> ne peut modifier qu’une liste blanche du principal, workingHours, photoBlobId et une clé d’un objet de capability, et seulement quand son droit nomme la collection qui ouvre ce canal, pas n’importe quelle délégation en écriture ; le nom, l’adresse et le fuseau restent fermés. Une photo posée par quelqu’un d’autre que sa personne (ce canal, ou un administrateur) doit être un blob de portée organisation que l’auteur a déposé (/jmap/upload-tenant/{tenantId}) ou peut lire, sinon invalidProperties avec un seul texte pour tous les cas (dire « ce blob est dans le compte de la personne » serait un oracle) ; chaque pose ou retrait de ce genre est une ligne d’audit au nom du compte authentifié.
• Principal/getAvailability (le libre/occupé) est documenté sur la page agenda.

​

D’une organisation à l’autre : la fédération

"urn:oximail:params:jmap:federation": {
  "supportedGranteeKinds": ["realm"],
  "revocationIsForwardOnly": true
}

​

Le bénéficiaire est une organisation, pas une personne

​

Le consentement ne se délègue pas

• Seul le sujet peut créer ou modifier un grant, en agissant sur son propre compte. Un administrateur peut révoquer, car la révocation retire un accès et un opérateur qui doit couper une fuite n’a pas à attendre le sujet, mais jamais accorder à la place de quelqu’un. Un grant qu’un administrateur peut créer pour vous n’est pas un consentement. Le contrôle est plus strict qu’un test de rôle : une requête qui porte un accès partagé, c’est quelqu’un qui agit pour un autre, quel que soit son niveau.
• Chaque écriture est une seule transaction : la ligne de grant, la ShareNotification qui prévient le sujet et la ligne d’audit qui nomme l’auteur de l’écriture valident ensemble. L’audit enregistre qui a réellement écrit, pas le compte que la requête visait : la révocation d’un administrateur n’est donc jamais attribuée au sujet.
• Un granteeKind non pris en charge est refusé bruyamment. "principal" s’analyse comme une requête bien formée et aurait l’air accepté ; la ligne créée serait un grant de realm portant le nom d’une personne.

​

Pourquoi un grant peut cesser d’agir, et comment le sujet l’apprend

• La révocation est unilatérale, immédiate, et ne vaut que vers l’avant. Un pair ne lit ni n’écrit jamais vos grants ; il apprend une révocation en se voyant refusé. C’est ce qui garde la révocation hors du terrain de la cohérence distribuée, et c’est aussi pourquoi revocationIsForwardOnly est annoncé comme donnée : révoquer retire le chemin de lecture pour la suite et ne défait rien de ce qui a déjà été divulgué.
• Le journal des divulgations est l’autre moitié de cette phrase. FederationDisclosure est ce qui rend « révoquer ne défait rien de déjà divulgué » vérifiable au lieu de simplement rassurant : il survit au grant, et il n’existe aucun FederationDisclosure/set, pas même limité au destroy. Enregistrer une divulgation fait avancer l’état de la collection du sujet dans la même transaction, si bien qu’un client qui surveille son propre journal le voit bouger. C’est la rétention qui borne le journal ; le sujet n’en efface rien. Il enregistre les divulgations, jamais les tentatives : un pair qui sonde cinq cents adresses ne crée aucune ligne au sujet des quatre cent quatre-vingt-dix-neuf personnes qui n’ont jamais consenti. Chaque ligne nomme le realm du pair, la couche d’identité vérifiée, la juridiction sous laquelle le grant se tenait à cet instant, et la date.