Placement de l'autorisation dans la couche de service plutôt que dans la couche API Web

Question

Je construis une API REST avec l'API .NET Core Web.

Mes contrôleurs simplement transmettre les demandes à la couche de service et de retourner le résultat

[HttpPost(nameof(Create))] 
public async Task<Response<ProviderDTO>> Create([FromBody] ProviderDTO provider) 
    => await providerService.CreateAsync(provider); 

Je suis au point dans le système maintenant où je dois commencer à mettre en œuvre l'autorisation.

.NET Core a a lot of options pour mettre en œuvre l'autorisation, mais la documentation traite principalement de ces approches dans le contexte de la couche Web (où les contrôleurs vivent évidemment). Mon instinct me dit que je dois implémenter l'autorisation dans la couche de service elle-même, plutôt que de placer cette autorisation sur la couche Web.

Certains de mon raisonnement comprend:

1. couche de service pourrait obtenir appelé par autre chose qu'un contrôleur (par exemple, les services d'appels d'autres services, qui ne seraient pas concernés à ce point avec autorisation) .
2. L'autorisation de service peut être testée unitairement directement, plutôt que de devoir compter sur des tests d'intégration écrits pour chaque "couche" devant les services.
3. Enregistre plusieurs appels dans la base de données - si j'ai besoin d'autoriser un document dans une exigence d'autorisation s'il est passé, je devrais retirer le même document plus tard dans le service.

Question Un

Serait-il une approche sensible et d'injecter IPrincipalIAuthorizationService dans mes services et de gérer l'autorisation directement là-dedans? Ensuite, la couche Web vérifierait purement simplement l'utilisateur est connecté, et peut-être des plus simples politiques attributs basés (c.-à ce contrôleur ne permet que la politique du personnel par exemple)

Question Deux

Est-ce que quelqu'un a des ressources dont ils ont pourrait me relier par (j'ai fait des recherches, mais il n'y a pas grand-chose là-bas à ce sujet)

PS: en ce qui concerne le rejet des demandes de la couche de service, j'ai un middleware de gestion des exceptions qui convertit des exceptions personnalisées pour les réponses HTTP. Ainsi, si une demande non autorisée se produit, je vais en lancer une pour une exception non autorisée qui aboutira finalement à un HTTP 403.

Answer 1

Tout dépend du type d'autorisation dont nous parlons et de la quantité de travail nécessaire ça arrive.

D'une manière générale, il n'est pas recommandé de mélanger votre couche de service avec la couche Web afin de les séparer.

L'autorisation Web est une chose - ici, vous dites que j'ai un utilisateur, est-il autorisé à accéder à ce point de terminaison/page/quoi que ce soit. Si ce n'est pas le cas, vous économisez des ressources en n'appelant même pas la couche de service et pouvez rejeter la demande dans la couche Web, très tôt dans le processus et très rapidement sans gaspiller de ressources.

Ensuite, de quoi est-ce que vous parlez? Est-ce celui qui parle réellement à la base de données ou est-ce celui qui fait une manipulation de données, une fois que vous avez les données de la couche de données?

Ma préférence serait d'avoir une couche de données et une couche d'autorisation séparées. La couche d'autorisation est celle qui applique toutes les règles dont vous avez besoin, puis renvoie le résultat de sorte que vous sachiez même si vous devez aller chercher des données ou non. Il n'est pas lié à votre couche Web, il ne renvoie pas les codes HTTP et n'a généralement rien à voir avec l'interface utilisateur. Cela signifie que si vous avez plusieurs clients, comme par exemple une interface utilisateur Web et une interface utilisateur mobile, les deux passeront par cette couche afin que ce niveau de travail ne soit pas dupliqué.

Mieux encore, vous voudrez peut-être créer une API appropriée pour renvoyer les données, alors tout ce que vous avez à faire est de traiter ce problème avec n'importe quel client et vous pouvez y gérer votre autorisation. Si vous vous assurez que vous pouvez appeler votre couche d'autorisation séparément de toute autre chose et ne dépendez de rien d'autre, vous pouvez l'appeler à partir de plusieurs endroits et la tester facilement et de manière indépendante.

C'est le genre de chose que les gens pensent avant de construire quelque chose, la sécurité n'est pas la dernière chose que vous ajoutez une fois que tout le reste est fait. Vous construisez votre produit en gardant à l'esprit que cela touche beaucoup de choses et qu'il influencera votre architecture.

Un diagramme de la façon dont tout s'assemble rendrait service.

• Quel type d'architecture avez-vous?
• Dans quelle mesure cette autorisation est-elle en cause?
• De quel type de clients parlons-nous?

Il ya beaucoup de questions à répondre avant que cela ne fonctionne.

Encore quelques points de moi, vous avez fait deux déclarations:

couche de service pourrait obtenir appelé par autre chose qu'un contrôleur (par exemple, les services d'appel d'autres services, qui ne être concerné à ce moment avec autorisation).

L'autorisation de service peut être testée unitairement directement, plutôt que d'avoir pour se baser sur des tests d'intégration écrits pour chaque "couche" qui passe devant les services.

1. si vous songez à microservices, alias beaucoup de petits services qui fonctionnent de façon indépendante, alors vous devez certainement vous préoccuper de la sécurité en fonction de la façon dont ces choses sont accessibles et communiquer entre eux. C'est pourquoi vous écrivez un calque d'autorisation, tout passe par là et c'est celui que vous testez sans vous soucier de l'interface utilisateur.