Discussion :

[Dunkhan]

Bonjour,

Dans le cadre d'un projet au sein d'une formation, nous devons réaliser une application web de type Uber.
Je dis de type uber pq'il s'agit, tout comme Uber, de donner la possibilité à des clients (ci après "Créateur") de créer des missions, et de l'autre coté, avoir des clients (ci apres "Worker") qui peuvent les accepter.

L'application est gérée et maintenue par nous (app Saas), elle est ensuite mise à disposition d'une société principale qui elle même la met à disposition d'autres sociétés.

La ou l'on bloque c'est sur la réalisation de la BDD et d'un schéma qui permet de gérer la granularité des droits utilisateurs et des profiles de société lié à chaque utilisateurs.
Sachant que l'on veut attribuer les droits aux utilisateurs sous forme de rôles plutôt que de droits direct (évidemment??!!).


Pour encore détailler plus.
Les utilisateurs de l'application sont découpé en plusieurs niveau :

• Le Super Admin qui gère l'application (nous)
• L'Admin Superviseur (l'administrateur de la société principale)
• Le Gestionnaire (l'administrateur des sociétés clientes)
• Le Créateur de mission(s) (le(s) employé(s) des sociétés clientes)
• Le Worker (L'utilisateur finale de l'app, accepte ou non les missions)

A savoir que :

• L'Admin superviseur à accès en lecture et écriture à tous les profiles (sociétés clientes et utilisateurs), ainsi que toutes les missions crées. Il peut créer/éditer/effacer des utilisateurs, société, missions. Il peut par ex : créer/editer une mission au nom d'un Créateur, la valider au nom d'un Gestionnaire et l'attribuer à un Worker.
• Le Gestionnaire (d'une société) doit valider les missions crée par ses Créateurs, et peut, comme l'Admin Superviseur, créer/éditer/effacer des utilisateurs, missions de sa propre société.
• Le Gestionnaire et le Créateur peuvent être une seule et même personne dans le cas de société avec très peu d'employés, ou dans le cas d'un employé chargé des deux rôles.
• Le Worker est une personne complétement indépendante (n'appartient à aucune société).
• Je sais que cela peut paraitre un peu bizarre, mais dans notre cas d'application, il se peut très bien que notre Admin Superviseur soit lui même un Worker, Gestionnaire dans une société et Créateur dans une autre (oui je sais, mais cela nous à été spécifiquement demandé, et le business model l'exige), et je crois que c'est point précis qui nous embrouille un peu sur le comment faire.

Ce que nous aimerions savoir c'est comment "diviser" les profils utilisateurs, les attribuer à un/des rôle(s) et au profil d'une ou plusieurs société(s). Et nous préférerions éviter la solutions de créer plusieurs profils pour un même utilisateur et le forcer à se (dé)connecter en permanence.
Pour ne pas "influencer" les réponses que vous pourriez nous donner, et avoir des réponses qui corrigent ce que nous fait jusqu'ici, je ne vais pas expliquer comment nous avons pensés le schéma de notre BDD.
Nous ne souhaitons pas avoir LA réponse, mais des pistes d'idées qui nous permettent de confronter la nôtre à celles que vous pourriez avoir.

Au cas ou, Laravel est utilisé pour le backend.

D'avance un tout grand merci à ceux qui prendront la peine de nous lire et d'apporter leurs idées


(Sur ce, bon dimanche ensoleillé)

[SQLpro]

Le plus simples pour gérer une sécurité efficace en matière de BD est de :
1) placer les objets de vos bases (tables, vues, procédures, UDF...) dans différents schémas SQL, à raion d'un schéma par pan fonctionnel. Exemple : CLIENT, COURSE, FACTURATION, GEO....
2) créer des rôles SQL adapté à la grande majorité des profils de sécurité
3) appliquer ces rôles SQL et les quelques privilèges SQL encore nécessaires à la combinaisons rôle/schéma

A +

[Michel.Priori]

La sécurité en 2 étapes est toujours une conversation.

En début de projet on pense que l'appli à venir sera le seul consommateur de la base.
Avec cette vision la solution de "refaire" la sécurité du coté applicatif parait le plus simple et le plus souple.
A l'usage cela conduit à une machine à gaz avec de multiples possibilités d'élévation de privilèges.

Pour continuer les propositions de SQLpro, je vous conseille de :

1- Si les "profils" utilisateur sont stables dans leur définition :
* d'utiliser la notion de schéma pour séparer les domaines de noms et les domaines de sécurité
-- domaine de nom : usage interne. Permet de répartir le volume des objets par "sujet"
-- domaine de sécurité : usage externe. Permet de recevoir des PS et les Vues qui encapsulent les PS et Vue internes
En affectant les droits au niveau du schéma l'espace des possibles est défini par le catalogue des objets présents

2- Si les "profils" utilisateur sont modulables via l'interface :
garder la notion de domaine de nom, c'est une valeur sûre
Créer autant de rôle que d'actions unitaires et les GRANTS associés.
Créer une interface qui permet, pour chaque profil, de créer des rôles (convention de nommage) et de gérer les GRANT et les REVOKE par rapport aux rôles unitaires.

puis viendra le problème de l'authentification.
a- continuité d'authentification :
gérer la délégation kerberos (problème du double hop) et prévoir de créer des groupes AD à l'identique des profils et associer les comptes utilisateurs aux groupes via l'interface applicative.
b- mappage d'authentification
un utilisateur de l'appli sera remappé en tant qu'un des utilisateurs "profil" (créer autant d'utilisateurs SQL que de profil)
Ps: bannir l'utilisation d'un compte "applicatif" qui lui serait dbo (et pourquoi pas sysadmin) car le contexte d'

puis viendra le problème de l'interface et de la gestion des droits.
Il faudra développer de manière à griser les actions en cas de non droit.