Authentification multiple en même temps

Bonjour, Bonsoir à tous,

Dans le cadre du développement de mon API Rest sous Symfony 3 je souhaiterai identifier l'utilisateur ainsi que le périphérique dans le même temps.

Concrètement j'ai besoin d'identifier le périphérique utilisé ainsi que l'utilisateur le manipulant.
Jusqu'à présent je n'ai identifier que l'utilisateur vu que c'est à ce niveau que porte les droits, et donc lorsque dans un contrôlleur je fais $this->getUser() cela me renvoie bien mon utilisateur.

Mon problème est que dans le tutoriel sur le SdZ à propos de symfony il est écrit

seul un unique pare-feu peut agir sur une URL

Hors je souhaite identifier les deux éléments dans le même temps sur les mêmes urls…

A un moment je me suis dit que c'était impossible, jusqu'à tomber sur un article disant:

À mois que vous ayez deux connections différentes sur votre application (système et utilisateurs), nous recommandons de n’utiliser qu’un seule firewall d’entré avec l’option anonymous activé.

Quand j'ai vu sa je me suis dit, c'est exactement sa que je souhaite faire ! Sauf que malgré mes recherches je ne trouve pas comment faire

Quelqu'un aurai-t'il une idée de comment pourrai-je identifier deux "utilisateur" (un serai un User et l'autre un Peripherique en même temps ? Techniquement on enverrai deux headers un identifiant l'utilisateur l'autre le périphérique.
Si on peut répondre par l'affirmative, comment dans le controller récupérer cette deuxième instance "utilisateur" ?

Merci d'avance pour vos indications.
Cordialement, La source.

Salut La source,

Tu veux juste savoir quel est le périphérique utilisé par l'utilisateur connecté ?

Malheureusement je ne puis me baser uniquement sur l'ip. L'idée est que chaque périphérique va recevoir un numéro de série l'identifiant lorsqu'il se connectera pour la première fois à l'API tel un token pour un utilisateur.

Je dois pouvoir identifier le périphérique, comme on pourrai le faire en mettant un cookie sur le navigateur d'un visiteur. Sauf que sur ce même navigateur un grand nombre d'utilisateur (devant s'identifier) peuvent passer. Hors je tiens de pouvoir identifier le périphérique.

Supposons que tu as un cookie qui s'appelle device et qui vaut une suite de caractère unique.

Si tu reçois une requête, tu vérifies l’existence de celui-ci :

• S'il existe alors c'est un périphérique que tu connais déjà ;
• Sinon, tu crées le cookie device pour marquer ce périphérique (Création de cookie avec Symfony).

Je ne vois pas pourquoi tu es parti sur les firewall ?

Parceque c'est une API Rest avec un stateless définit à vrai… normalement l'idée même de cookie ne devrai pas exister. Je dois donc envoyer un header plutôt.

Le truc c'est que dans mes contrôller j'aimerai pouvoir savoir quel est le terminal (donc une entité) qui exécute la requête.

Et que si un terminal n'est pas "inscrit" il n'a pas le droit d'accéder à l'API sinon à la route d'inscription.

Un cookie, c'est un header Set-Cookie . Avec l'avantage que le navigateur le renvoie au serveur automatiquement. Le stateless true de Symfony interdit le cookie de Session mais pas le reste.

Je ne sais pas quel est l'objectif final mais comment comptes-tu inscrire un terminal ? Qu'est ce que tu veux obtenir comme résultat en exigeant l'inscription des terminaux ?

C'est un problème de licence d'utilisation.

On vends des licences par rapport au nombre de canaux, concrètement si un client achète une licence pour deux canaux il peut utiliser au maximum 2 terminal simultanément (il peut cependant avoir 8 terminaux avec l'application cliente installée, on parle ici d'utilisation simultanée).

J'ai donc besoin d'identifier les terminaux de la même façon qu'un utilisateur au sens Symfony du terme afin de savoir s'il à le droit d'aller plus loin ou au contraire si on dépasse la limite d'utilisation accordé par la licence.

Ok je vois mieux maintenant.

En réalité ton problème de base n'est pas lié à Symfony. C'est un problème générique sur comment identifier de manière unique un équipement (je t'invite à modifier le titre pour attirer plus de monde).

Si cet équipement est un navigateur, un cookie reste un bon compromis même si l'utilisateur à le pouvoir de le supprimer. Un peu de doc.

Si l'équipement est une application mobile, chaque fournisseur dispose d'une méthode. Sur Android par exemple, tu as la valeur de Settings.Secure.ANDROID_ID qui elle aussi n'est pas fiable à 100%.

Le seul rôle que pourrait jouer l'API ici c'est d'exiger un paramètre (un header X-User-Device par exemple) qui doit contenir l'identifiant de l'équipement. Mais ça sera aux codes clients (applications mobile ou site web) d'envoyer cet entête dans toutes leurs requêtes.

Salut,

Il faudrait que tu nous détailles un peu plus l'application cliente pour qu'on puisse identifier les contraintes. Dans certain cas il est très facile de modifier l'empreinte, fingerprint, d'une application. Et il est important de prendre soin de protéger (encrypter) la communication, pour éviter que l'empreinte soit modifier par une application tiers de type proxy.

Mais sachant que tu parles de sessions simultanées, à ta place, j'essayerai plutôt de compter le nombre de devise connecté, plutôt que d'essayer d'identifier les devises. Il y a-t-il une importance de savoir s'il s'agit de la devise 43, 44 ou 45 ?

En effet, il suffirait simplement de supprimer les sessions qui dépasse le quota en fonction de l'ordre d'inactivité, attribut leur une id de session dès la connexion à l'application.

Ensuite si la communication est de type Ajax c'est-à-dire Synchrone, demande une clé de type "token" que tu demandes, modifies et renvoies à chaque fois.

Il y a évidement toujours moyen de contourner les protections, cependant je ne cherche pas un système à toutes épreuves, le but ici c'est que pour un utilisateur lambda, s'il essaye d'utiliser un troisième terminal alors qu'il est limité à deux canaux, aie une erreur.

Par ailleurs pour répondre à la remarque, j'ai l'intention de mettre en place un certificat ssl sur le serveur et l'application cliente devra vérifier que c'est bien notre certificat pour continuer la communication. Donc un proxy serai mis en échec.

Par contre, oui, je dois pouvoir identifier un terminal, en ce sens où les manipulations effectuée sont loguée et on enregistre quand, qui, quoi et où (le terminal).

Pour y arriver le principe que j'image est que le terminal doit s'enregistrer sur le serveur pour pouvoir communiquer avec lui.
Concrètement l'application cliente vois qu'elle n'a pas de token, elle appelle une route sur le serveur qui lui renvoie un token (dans cette requête l'utilisateur va devoir spécifier le mot de passe admin d'être sur que le terminal ajouté est autorisé à se connecter au serveur) ce token servant à identifier le terminal par la suite.

Alors certes, si un petit malin va sur un périphérique et récupère ce token pour le copier sur un autre périphérique alors le serveur ne verra qu'un seul et unique périphérique. Le truc c'est qu'il n'y a pas d'autre solution vu que c'est une API donc "stateless", le concept même de session n'existe pas. Sans compter que dans l'absolu on parle de moins de 1% de nos utilisateurs qui pourraient faire sa, le risque est donc limité.