# Travail sur les WebACL

## Rappel des décisions précédentes

### Identification utilisateur

Fuseki reçoit du middleware un header `X-SemappsUser` avec:
- Le webID de l'utilisateur connecté
- `anon` si l'utilisateur n'est pas connecté
- `system` s'il faut ignorer les ACL complètement (*bypass*)

Il faut empêcher d'accéder à Fuseki directement, sinon toutes les données privées seraient potentiellement accessibles (il suffira de passer "system" ou un webID).

Problèmes restants:
- Il pourrait être utile d'avoir des utilisateurs super-admin, qui peuvent tout modifier. Comment on les identifieraient ? Est-ce que le middleware, lorsqu'il les identifierait, passerait le mot-clé `system` ?
- Cela sera géré par le middleware, qui passera le mot-clé `system`.

- bloquer le port dans docker pour empecher des requetes sparql directes sur JENA.? pertinence à vérifier étant donné l'authentification user/psw actuel.
- Non: mais mettre un mot de passe plus solide ;-)
- Attention à ce que l'on puisse encore faire les requêtes SPARQL depuis l'interface Fuseki
- Faire attention à ce que l'on puisse pas passer le header X-SemappsUser depuis l'exetrieur pour se faire passer pour le middleware

### Scope

Les WebACL s'appliquent aux ressources, non aux triplets.

Nous avions eu [beaucoup de réflexions](https://hackmd.io/3C6sYZvAT9-Q2G33lWiXVQ) pour voir s'il était possible d'attacher des WebACL à des triplets, mais ça semblait compliqué. Il faudrait en effet passer par du RDF* ou d'autres mécanismes de ce genre.

Depuis la version 3.16, RDF* est activé par défaut dans Fuseki. https://jena.apache.org/documentation/rdfstar/

Cependant les specs LDP / WebACL ne prennent pas en considération les triplets, mais seulement les ressources. Nous n'allons donc pas utiliser ça pour le moment.

S'il faut cacher des données, par exemple un email, on pourra toujours les mettre dans une ressource différente qui sera, elle, protégée.

Commentaires:
- Réflexions autour des données privées et publiques, comment faire la réconciliation? Passer par `owl:sameAs` pour gérer l'inférence?
- Les contacts pourraient être dans une classe à part.
- Faire attention à bien diviser en classes petites

### Business logic

Toute la business logique est faite du côté middleware.

Fuseki vérifie les ACL lors des requêtes SPARQL (read / write), mais c'est le middleware qui s'occupe d'ajouter les ACL, par exemple au moment de la création d'une ressource. Pour Fuseki, il n'y a d'ailleurs pas de création de ressource, il n'y a que des triplets.

Intérêts:
- Pas trop de dépendences à Fuseki, pour permettre une migration éventuelle dans le futur.
- Plus facile à coder.
- Fuseki n'a pas de concept de ressources, il n'y a que des triplets.

## Questionnements

### Dataset ou Graph différent

Questions:
- Est-ce qu'on met les triplets webACL dans un dataset différent?

Décisions:
- Pour le moment on va mettre tout dans le même dataset car cela simplifie le travail. On verra plus tard s'il y a besoin des les déplacer dans un dataset différent.
- On va par contre les mettre dans un graph différent, cela évitera que des triples WebACL ressortent lors de requêtes simples.
- Au final, du a un bug du coté de Jena Permissions, les données ACL sont bien enregistrées dans un graph nommé séparé, mais ce graph nommé est stoqué dans une database séparée (datasetTDB). Mais les 2 graphs sont accessibles ensemble dans le Dataset virtuel `localData`

Problème:
- Comment empêcher l'endpoint SPARQL public d'aller requêter les triplets dans le graph dédié au WebACL ? Sinon, est-ce que ça nous oblige à créer un dataset différent ?
- **Thomas**: Dans la config du Dataset Fuseki, il est possible de restreindre certaines URLs à l'interrogation de certains graphes seulement, et de cacher le graphe des ACL : https://jena.apache.org/documentation/fuseki2/fuseki-data-access-control.html#graph-acl Par contre cela demande de connaitre à l'avance l'organisation du Dataset en graphes nommés.
- Les permissions peuvent être implementées aussi avec la classe Java des permissions ACL

Décision:
- On voit pour activer cette configuration sur l'endpoint SPARQL de Fuseki qui est utilisé pour l'endpoint public /sparql.
- ça a été implémenté au final avec le mecanisme des permissions de Shiro/Jena. L'endpoint SPARQL n ést pas public. Il est protégé par un mot de passe (user admin). Si le middleware veut exposer un service SPARQL de manière publique, il doit le faire en passant le Header `X-SemappsUser: anon` à Fuseki.

### Containers

Dans les specs WebACL, on peut gérer les [droits sur les containers](https://github.com/solid/web-access-control-spec/blob/master/README.md#containers-and-inherited-acls). Les ressources qui sont créées dans un container ont par défaut les droits du container, si une propriété `acl:default` est définie.

La spec parle aussi de **root containers** dans lesquels il est obligé de définir les droits par défaut. (Côté SemApps, nous avons prévu de mettre en place des containers racine, voir [#429](https://github.com/assemblee-virtuelle/semapps/issues/429))

Attention:
- La notion de `acl:default` ne correspond pas à une template. On ne peut pas dire par exemple: "toute resource créée par une personne va donner un droit `acl:Control` à cette personne", car il n'y a pas de notion de propriétaire. Cela devra donc être défini au niveau du middleware (voir la section "Resources owners" plus bas)

Questions:
- A quoi correspond `acl:Append` pour les containers et pour les resources ?
- Pour les containers: possibilité d'ajouter une nouvelle resource dans le container.
- Pour les resources: possibilité d'ajouter des triplets à la resource, mais pas d'en supprimer.
- A quoi correspond `acl:Write` pour les containers ?
- possibilité de modifier les paramètres du container (nom?, ... quoi d'autre?)
- possibilité d'ajouter ou d'enlever des resources. Si la ressource est contenue uniquement dans ce container, alors elle doit etre supprimée au moment ou elle est enlevée du container. Ceci ne peut etre fait que si l'utilisateur à le droit WRITE sur la resource.
- ~~Possibilité d'ajouter des resource ou de supprimer le **lien** vers certaines resources. La suppression de la resource elle-même dépend de ses propres ACLs.~~

Remarques:
- Il n'y a pas la notion de permissions restrictives. Donc ça veut dire que si on défini un `acl:default` sur le container racine en donnant tous les droits, cela voudra dire que toutes les ressources sont lisibles.
- Cela va poser des questions d'UX
- Sujet à discuter dans un cadre plus large (SOLID, etc)

### Edition en mode anonyme

Avec SemApps nous voulons mettre en avant des modes d'édition ouverts type "wiki" qui permettent à des utilisateurs d'ajouter ou modifier des ressources sans même être connecté sur un compte.

Cependant certaines instances SemApps voudront peut-être obliger les utilisateurs à être au moins connectés.

La spec WebACL gère les deux cas: [accès public](https://github.com/solid/web-access-control-spec/blob/master/README.md#public-access-all-agents) et [agents loggés](https://github.com/solid/web-access-control-spec/blob/master/README.md#authenticated-agents-anyone-logged-on).

Questions:
- Comme toutes les ressources sont en principe dans un container, se basera-t-on systématiquement sur les droits par défaut du container ? Ou faut-il prévoir les cas où aucun ACL n'est défini ?

Solution:
- La spec oblige à définir des droits par défaut dans le "root container" https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm-example Pour définir le comportement par défaut de toute l'instance SemApps, il suffit donc de mettre des ACLs sur ce "root container".

### Resources owners [#573](https://github.com/assemblee-virtuelle/semapps/issues/573)

Dans les dernières specs de WebACL, il a été décidé de ne pas prendre en compte la notion de [Resource Owner](https://github.com/solid/web-access-control-spec/blob/master/README.md#resource-owners).

Décision:
- Quand un utilisateur crée une ressource, il suffira de lui donner les droits `acl:Read`, `acl:Write` et `acl:Control` sur cette ressource. Ce sera fait par le middleware.
- Si la ressource est créée par un utilisateur anonyme, on pourrait en revanche donner les droits `acl:Read` et `acl:Write` à tous les agents.
- On pourrait définir quelque part quels sont les droits par défaut.

Remarques:
- Il faudrait prévoir des super-admins qui pourraient ajouter des droits `acl:Control` sur les ressources qui ont été créées des utilisateurs anonymes.
- Si un utilisateur donne un droit `acl:Control` à qqn d'autre, cette personne peut nous enlever les droits. -> UX

### Gestion des erreurs [#574](https://github.com/assemblee-virtuelle/semapps/issues/574)

Si on essaie de faire une requête `acl:Read` sur des ressources qui ne sont pas visibles par l'utilisateur connecté, celles-ci ne sont simplement pas retournées: elles n'existent pas.

Par contre si on essaie de mettre à jour des ressources sur lesquelles l'utilisateur n'a pas le droit, il faut que Fuseki retourne une erreur 403, et que le middleware renvoie cette même erreur au front.

Si on fait une requête de type `DELETE { } INSERT { } WHERE { }` et que l'utilisateur a seulement le droit `acl:Append`, l'`INSERT` va fonctionner mais pas le `DELETE`. Dans ce cas, toute la requête est refusée. (vérifé sur Fuseki)

Problèmes restants:
- pour le moment c'est une erreur 500 avec le texte "Triple permissions violation" qui est retournée par fuseki. À charge du midleware de la convertir en 403 > faire une remontée en issue chez Jena
- apparement Jena demande la permission UPDATE pour les mises à jour de triplets dans des séquences ordonnées et des listes RDF. Pas testé pour le moment.

Remarque: nous considerons que la permission WRITE donne aussi la permission READ implicitement (ce n'est pas dans les specs mais ça fait sens)

### Groupes [#575](https://github.com/assemblee-virtuelle/semapps/issues/575)

Les specs WebACL permettent de définir des [groupes d'agents](https://github.com/solid/web-access-control-spec/blob/master/README.md#groups-of-agents). On peut ensuite donner les droits d'une ressource à un groupe plutôt qu'à un utilisateur en particulier.

Réflexions:
- Il peut y avoir plusieurs groupes sur une même organisation. On ne peut donc pas utiliser le webID de l'organisation pour identifier l'organisation.
- Lorsqu'on crée une organisation, on pourrait créer un `vcard:Group` et lorsqu'on y ajoute des responsables (p.ex.), on les marquent comme membre (`vcard:hasMember`) de ce groupe.
- Il faudra trouver le moyen adéquat pour synchroniser les données métiers avec les groupe WebACL avec l'organisation (PAIR par exemple), par exemple avec un service.

Idées complémentaires:
- Il serait peut-être utile de pouvoir avoir des informations sur un groupe, via un URL particulier. Par exemple `/organizations/semapps/groups/admin` ? Avec un tel URL, on pourrait même en déduire l'organisation concernée et se passer de prédicats.

Remarques:
- Il faudrait qu'on puisse créer manuellement des groupes, ajouter des membres, etc.
- Gérer avec inférence type `owl:equivalentProperty` ?
- Héritage de propriétés
- Faudrait activer le moteur inhéritence de Jena ?
- Les données des groupes ne seraient pas dans le graph avec les webACL.

### Voir les droits sur une ressource LDP [#571](https://github.com/assemblee-virtuelle/semapps/issues/571)

En terme de frontend, c'est très utile de pouvoir connaître les droits sur une ressource. Cela évite par exemple de mettre un bouton "Editer" si l'utilisateur n'a que des droits de visualisation. Cela évite d'attendre l'erreur 403 !

Solution:
- Il existe une [spécification](https://github.com/solid/web-access-control-spec/blob/master/README.md#acl-resource-location-discovery) pour découvrir les ACL d'une ressource.
- La spec renvoie un fichier de type `resource.acl`. Comme nous ne fonctionne pas sous forme de fichiers, on pourrait renvoyer, pour une ressource `http://localhost/projects/project-slug`, un URL de type `http://localhost/_acl/projects/project-slug`. Cela serait plus simple à gérer côté Moleculer.

Problèmes restants:
- Est-ce que les ACLs sont une données publiques ? D'après les [specs](https://github.com/solid/web-access-control-spec/blob/master/README.md#aclcontrol), "`acl:Control` is a special-case access mode that gives an agent the ability to view and modify the ACL of a resource". On en déduit donc que quelqu'un qui n'a pas le droit `acl:Control` ne peut pas voir les ACLs.
- On permettra tout de même que quelqu'un qui n'a pas ce droit `acl:Control` puisse au moins voir ses propres permissions.
- L'affichage des ACLs d'une ressource sera la responsabilité du service Moleculer. Il s'occupera de la requête SPARQL. Fuseki ne s'occupe pas de filter les triples webACL, puisque de toute façon le graph avec les triples webACL n'est pas accessible depuis l'endpoint SPARQL public.
- Si la ressource n'a pas de permissions spécifiques, il faut que l'endpoint _acl retourne les permissions par défaut du container parent.
- Les ACLs sur les fichiers non-RDF doivent-ils être gérés d'une manière particulière ?
- Au niveau de l'action `ldp.resource.get`, il faudra vérifier que l'utilisateur a droit d'accès à cette ressource.
- Pour voir les droits sur le container racine, il suffirait de regarder l'URL /_acl

### Modifier les droits sur une ressource LDP [#572](https://github.com/assemblee-virtuelle/semapps/issues/572)

Il serait aussi important que, depuis le frontend, on puisse facilement changer les droits sur une ressource. Il faudrait pour cela passer par des standards.

Dans les [anciennes specs](https://www.w3.org/wiki/WebAccessControl), il est expliqué le moyen de modifier les ACL d'une ressource LDP. Mais cela passe par une requête SPARQL update (`application/sparql-update`) qui semble dangereuse et sans doute plus trop d'actualité.

Il est indiqué dans les implémentations que, dans le projet [rwwPlay](https://github.com/read-write-web/rww-play), les ACL sont éditables en utilisant le protocole LDP.

Cette dernière approche semble plus cohérente que du SPARQL update.

Solutions:
- On fait un PUT ou PATCH sur l'endpoint `/_acl/{resourceUri}`
- Cette opération n'est autorisée que si l'utilisateur connecté à un droit `acl:Control`

Il serait intéressant de connaître l'avis de l'équipe SOLID ou Startin'Blox sur ce point.

# Service Moleculer `webacl`

## Dépendences

- `triplestore`
- `ldp.container` (pour connaître les options sur un container ?)

## Settings

- `graphName`: nom du graph où se trouvent les triplets webAcl

## Actions

- **Gestion des droits sur les ressources** (`webacl.resource`)
- `setRights({ resourceUri, userUri | groupUri, modes: { read, write, control, append } })`
- Défini les droits d'un utilisateur sur une ressource
- `getRights({ resourceUri, userUri | groupUri })`
- Retourne les droits d'un utilisateurs sur une ressource
- `hasRight({ resourceUri, userUri | groupUri, mode })`
- Retourne true or false
- **Gestion des droits sur les containers** (`webacl.container`)
- `setDefaultRights({ containerUri, webId })`
- Défini les droits `acl:default` sur le container
- **Gestion des groupes** (`webacl.group`)
- `create({ groupUri })`
- Crée un `vcard:Group` avec l'URI indiqué
- `attach({ resourceUri })`
- Attach le type `vcard:Group` à une ressource existante ?
- `addMember({ groupUri, userUri })`
- Ajoute un utilisateur dans un groupe (`vcard:hasMember`)
- `getMembers({ groupUri })`
- Retourne tous les membres du groupe
- `isMember({ groupUri, userUri })`
- Retourne true si l'utilisateur est déjà membre du groupe

## API routes

- `GET /_acl/{resourcePath}`
- Retourne les droits sur la ressource.
- Si l'utilisateur a un droit `acl:Control` sur la ressource, retourne toutes les informations, sinon retourne seulement les informations qui concerne l'utilisateur connecté.
- Si la ressource n'a pas de droits spécifiques, retourne les `acl:default` du container parent.
- Si la ressource est un container, retourne les droits du container.
- `PATCH/PUT /_acl/{resourcePath}`
- Ajoute, modifie ou supprime des droits sur la ressource indiquée. Le format doit être le même que pour l'ajout de données sur un serveur LDP.

# Resources:

- https://github.com/solid/web-access-control-spec/blob/master/README.md
- https://www.w3.org/wiki/WebAccessControl
- https://github.com/AtomGraph/LinkedDataHub/blob/master/src/main/webapp/WEB-INF/web.xml

# snippet for inheritance of property

# Sélectionner tous les membres d'un group...
SELECT ?member
WHERE {
  # soit en lisant les membres directs du groupe
  { ?group vcard:hasMember ?member . }
  UNION
  # soit en lisant n'importe quelle propriété qui serait déclarée 
  # comme sous-propriété de vcard:hasMember
  { 
    ?group ?anyLink ?member .
    ?anyLink rdfs:subPropertyOf vcard:hasMember .
  }
}