Quels schémas d'authentification et d'autorisation utilisez-vous - et pourquoi ?

Question

Nous commençons à concevoir toute une série de nouveaux services à créer (WCF, ADO.NET Data Services, éventuellement dans le nuage à un moment donné) et l'une des questions qui se posent est de savoir quel schéma d'authentification et d'autorisation utiliser - il y en a plusieurs !

Nous devons essentiellement être en mesure d'identifier les utilisateurs (personnes réelles et utilisateurs "virtuels" d'applications/services) sur une grande variété de protocoles - HTTP, HTTPS, TCP - et nous devons leur attribuer au moins un ensemble de rôles/permissions de voir certaines données et/ou d'effectuer certaines opérations.

Nous ne pouvons absolument pas nous contenter d'utiliser l'appartenance à un groupe Windows - nous avons beaucoup de consommateurs externes de nos services et nous ne voulons pas avoir à configurer un compte de domaine dans notre domaine interne pour chacun d'entre eux.

Il y a donc principalement trois options, je pense :

1. Utilisation du système d'adhésion ASP.NET - créer des utilisateurs et leur attribuer des rôles
2. utiliser AzMan (Authorization manager) qui semble être un système plus granulaire, plus mature, plus élaboré (avec des utilisateurs, des tâches, des groupes - trois niveaux, pas seulement utilisateur + rôles)
3. Roulez nos propres

Tout d'abord, laquelle de ces trois options recommandez-vous ? Et pourquoi ?

Deuxièmement, y a-t-il d'autres options qui me manquent ?

Merci pour tous les conseils, les pointeurs, les opinions !

Marc

PS : en voyant les réponses jusqu'à présent, je suis étonné par le nombre de personnes qui ont voté pour l'option 3. J'aurais pensé que MS serait capable de concevoir quelque chose de réutilisable qui pourrait gérer toutes ces exigences.....

Answer 1

En fait, la réponse est probablement une combinaison de 1 et 3.

Vous pouvez tirer parti d'un grand nombre d'outils et de fonctionnalités que le framework met à votre disposition en écrivant un fichier de type adhésion , rôle ou profil si les options par défaut ne vont pas aussi loin que vous le souhaitez.

C'est ce que nous avons fait sur un certain nombre de sites clients - par exemple, l'un de nos clients a la plupart de ses utilisateurs stockés en tant qu'utilisateurs de Commerce Server, et utilise le système de profil de Commerce Server, nous avons donc écrit un fournisseur d'adhésion et de profil pour parler à ces magasins de données - un exercice assez simple.

---

La plupart des gens choisissent probablement le niveau 3 en raison de la nécessité de s'authentifier sur du TCP brut, ce qui introduit une couche supplémentaire par rapport à la norme. ASP.NET les fournisseurs d'adhésion.

La plupart des produits MS sont "corrects" ou "suffisamment bons", mais il y aura toujours des cas limites où vous voudrez faire quelque chose de "pas tout à fait standard", ce qui signifie que vous finirez par développer votre propre produit. Je suppose que pour avoir quelque chose de plus que "Basic Auth" ou "Windows Auth" qui soit simple à comprendre pour le développeur moyen, ils ont pris l'option raisonnable de "construisons simplement cela pour le web".

Si vous jetez un coup d'oeil aux nombreuses manières que vous pouvez authentifier contre un service de WCF, vous verrez ce que je veux dire - ceux-ci sont conçus pour gérer différents mécanismes de transport, et sont donc beaucoup plus complexes.

Cela dit, les fournisseurs de rôles et de profils par défaut sont assez limités (rôles : pas de hiérarchie, il faut donc vérifier chaque rôle possible, ou attribuer explicitement chaque rôle à l'utilisateur ; profils : tous stockés dans un champ sous forme de valeurs séparées par des virgules - pas facile de trouver tous les utilisateurs qui ont une valeur définie).

Answer 2

Nous utilisons (3). En fait, cela nous a aidé dans un paysage d'intégration pour avoir des comptes en synchronisation avec

1. les processus opérationnels
2. Autres systèmes (pas tous sur la même pile technologique (ASP.NET))

Answer 3

Dans le cadre d'un projet récent, nous avons étendu le fournisseur d'adhésion ASP.NET (en écrivant un fournisseur personnalisé) dans l'intention d'utiliser certains des contrôles basés sur les rôles pour gérer les autorisations. Maintenant que le projet a suffisamment mûri, nous constatons que les contrôles ne sont pas assez flexibles pour nos besoins et, dans une certaine mesure, nous regrettons d'avoir emprunté la voie de l'adhésion à MS. La meilleure option consiste à mettre en place sa propre authentification si l'on a le temps de l'architecturer correctement.

Il semble que votre application soit un peu hybride dans la mesure où vous servez des clients internes et externes, mais vous devriez peut-être envisager d'intégrer OpenID pour vos clients externes. Il existe d'excellents contrôles ASP.NET OpenID qui facilitent la gestion des nouveaux comptes pour les clients externes. Cela dépend bien sûr du caractère "public" de votre application.

Answer 4

Ldap quelqu'un ? Il est gratuit, multiplateforme, facile à utiliser et à administrer à distance, dispose de passerelles vers d'autres systèmes d'authentification et de liaisons dans plus de langues que vous ne le pensiez...

Answer 5

AZMan ne date-t-il pas de 2003 ?

Je recommanderais 1 ou 3. Personnellement, j'ai toujours opté pour 3. Il y a beaucoup de fonctionnalités de la version 1 que je n'utilise pas ou que je ne souhaite pas utiliser.