Discussion :

[thlac]

Bonjour,

Je cherche à mettre en place une architecture Microservices pour une solution applicative développée en C# / Asp.Net MVC.

Cependant, bien que j'arrives à conceptualiser (voir diagramme de séquence joint) les interactions entre mes services "métier", mon service d'authentification et mon service d'autorisation, je n'arrive pas a comprendre techniquement comment le mettre en œuvre.



Pour le service d'authentification, je suis parti sur une simple WebApi avec authentification par compte utilisateur individuels.
Je me doute que je peux le faire manuellement avec HttpClient pour chaque requête, mais le but de la manœuvre est d'automatiser tout ça.
Mais mon idée serai de pouvoir continuer à me servir de l'attribut "Authorize" en le personnalisant pour qu'il prenne en paramètre : "Contrôleur" et "Action".
Ainsi dans mon service d'autorisation, je regarde pour l'application appelante, si l'utilisateur fournit par le service d'authentification est autorisé à appeler l'action donnée du contrôleur donné.

En gros, toute la partie en rouge sur le diagramme, serait exécutée par la simple utilisation de l'attribut "Authorize" sur la méthode appelée.

Sauf que la dedans, je ne vois pas comment mes services métiers peuvent savoir que l'attribut Authorize doit aller vérifié si l'utilisateur est connecté dans un autre service.
Je pourrais créer un nouvel attribut Authorize qui hérite de celui du framework (c'est ce que j'ai fait pour avoir le contrôleur et l'action), mais je ne sais pas comment, depuis le code de cet attribut rediriger vers une page de connexion en cas d'échec de l'authentification.
D'ailleurs, je ne vois même pas où je dois implémenter mes vues d'inscription / connexion, pour ne pas avoir à les redévelopper pour chaque service métier.

Est-ce clair ? Je suis moi-même un peu perdu dans ma tête.

Peut-être que je me prends la tête et que AspNet Identity prévoit déjà la connexion multi-applications. Mais dans ce cas, avez-vous des tutos à me donner, je n'en trouve aucun.

A bientôt,
TL

[DotNetMatt]

Ben ton schema repond a ta question, sauf que tu oublies de parler de l'element principal de ce type d'architecture : le token.

C'est lui qui te permet de savoir si tu es authentifie sur un autre systeme ou non. Ce token peut prendre la forme de tout est n'importe quoi : un entete HTTP, un cookie, etc.

Un exemple d'archi sur laquelle j'ai bosse dans une grosse entreprise Francaise :
- L'utilisateur arrive sur un portail Web public. Ce portail dispose d'un formulaire d'authentification pour pouvoir acceder aux fonctionnalites specifiques.
- Lorsque l'utilisateur s'identifie, on envoie les identifiants a in WAM (Web Access Manager) qui s'appuie sur un IAM (Identity Access Manager). Le premier verifie les autorisations d'acces aux URLs, et le second verifie l'authentification.
- Quand le IAM detecte que l'identite est valide, il renvoie un token (en l'occurence une entete HTTP).

Le principe reste le meme avec un cookie.

En gros tu dois personnaliser ton AuthorizeAttribute pour qu'il verifie la presence et la validite du token, sur tes systemes clients. Une autre solution plus propre a mon sens est d'utiliser OWIN ou Katana et de developper un middleware qui se chargera de faire ce genre de verifications. L'avantage c'est que ta verification interviendra plus tot dans le cycle de vie de la requete HTTP, ce qui sera plus performant et evitera des cycles CPU inutiles (l'attribut etant utilise plus loin qu'un middleware dans le pipeline).

[thlac]

Merci Matt,

Donc si je comprend bien, je peut tout coder dans mon attribut.
Mais où je met mes pages de connexion / inscription ... avec mon service d'authentification. C'est lui qui fourni les vues ?
Et comment je redirige vers elles depuis le code de mon attribut ?
Et je ne suis pas sur de savoir comment récupérer mon token depuis l'attribut non plus. Je passe par un singleton ou une classe statique avec une variable globale ? parce que je n'ai pas accès à mon contrôleur, ni à la session.

Je vais regarder la piste du middleware également. Cela implique t-il vraiment de grosse différence de performances ?
Je suis parti sur l'attribut au départ parce que je ne trouvait rien de mieux, mais il me semble que ça fait beaucoup d'appels sous-jacents pour chaque appel d'un service.


A+,
TL

[DotNetMatt]

Mais où je met mes pages de connexion / inscription ... avec mon service d'authentification. C'est lui qui fourni les vues ?

A toi de voir, soit tes vues sont gerees par le service d'authentification, soit elles sont ailleurs et le service d'authentification recoit simplement les identifiants.

Et comment je redirige vers elles depuis le code de mon attribut ?

Regarde la doc de l'attribut, il suffit de surcharger certaines methodes.

Et je ne suis pas sur de savoir comment récupérer mon token depuis l'attribut non plus. Je passe par un singleton ou une classe statique avec une variable globale ? parce que je n'ai pas accès à mon contrôleur, ni à la session.

Il ne faut jamais utiliser de singleton et autre truc global dans une appli Web, sauf s'il y a une raison precise de partager des infos identiques entre tous les utilisateurs.

Je vais regarder la piste du middleware également. Cela implique t-il vraiment de grosse différence de performances ?

Si ton service gere 100 requetes par jour, ca ne sera pas flagrant. Par contre si tu as un volume d'utilisateurs important, et/ou si tu es heberge sur le cloud, il faut optimiser ce genre de choses.

On ignore la sensibilite des donnees fournies par ton projet, mais je me permet une mise en garde ici, car tout ca a l'air assez nouveau pour toi. Je te conseille fortement de te document en profondeur sur l'authentification (tu peux compter plusieurs semaines) car si tu rates une etape ou si tu implementes incorrectement ton protocole d'authentification, tu peux tres facilement creer des failles de securite et donc mettre ton systeme a risque. Il existe deja des protocoles bien definis comme OAuth, OpenID, SAML, etc. et ils sont deja supportes par ASP.NET Identity donc peut-etre vaut-il mieux t'orienter vers une de ces solutions plutot que de chercher a implementer ta propre solution totalement custom.