2

Je travaille sur un projet qui permet à un utilisateur de créer un utilisateur pour créer des clés d'application ou des secrets afin que des services spécifiques puissent être utilisés par des clients externes. Un utilisateur peut créer plusieurs secrets qu'il peut choisir d'utiliser sur plusieurs clients. Pour cela, je prévois de créer un serveur d'authentification découplé qui utilisera identityserver4. Ce qui me retient vraiment, c'est que je ne sais pas si je devrais créer une couche API sur le serveur d'authentification. La raison pour laquelle je considère API au serveur d'authentification est que je peux créer une sorte de client portail d'administration qui donnera aux utilisateurs une interface pour créer, renouveler et accéder à leurs clés/secrets d'applications. Même le portail d'administration va être une application angulaire découplée.Plusieurs clients externes pour les utilisateurs sur identityserver4

Il y a deux choses qui me retenaient au moment:

  1. Je ne suis pas sûr que ce soit une bonne idée ou sûr de servir ces données via une couche api. D'après ce que je comprends, identityserver ne sera pas en mesure de fournir une fonctionnalité qui me permet d'accéder à une liste de clients d'un utilisateur via un point de terminaison, mais corrigez-moi si je me trompe et qu'il y a une meilleure approche. Je sais que nous pouvons facilement créer de nouveaux clients et les conserver dans la base de données avec identityserver4 et que je prévois d'utiliser les types de subvention ClientCredentials pour les clients utilisateurs, mais existe-t-il un lien entre un utilisateur et un client? Ou devrais-je créer cette fonctionnalité par moi-même?

Jusqu'à présent, j'ai regardé, mais je n'ai pas abeille en mesure de trouver des exemples similaires à ma situation avec identityserver4

Désolé pour la question de noob, je suis juste dans la sécurité identityserver et web en général tant de ces concepts sont encore très nouveaux pour moi.

Répondre

1

Pour le numéro 1, je dirais que oui, vous pouvez créer une couche API pour les données du serveur. Si vous cochez IdenttiyServer4 AdminUI, Rock Solid utilise également l'API d'administration derrière l'interface utilisateur. Mais vous devez envisager le cryptage, TLS et autres mécanismes de sécurité pour garder cette sécurité. AFIK pour le numéro 2, il n'y a pas de liens au niveau de l'identité entre un utilisateur et un client. Vous devez créer cela par vous-mêmes.

Fondamentalement, vous avez besoin d'un système qui prend en charge Multitenancy. Je l'ai réalisé en ajoutant un champ TenantId dans la table utilisateur AspNetIdentity. Et a également ajouté l'ID de locataire à la liste de réclamation.

S'il vous plaît ne pas hésiter à me corriger si je me trompe.

+0

Merci. Cela a éclairci la plupart de mes préoccupations. Just n'était pas sûr de la liste de réclamations que vous vouliez dire ici: "Et aussi ajouté la liste des locataires à revendiquer". Mais je suppose que vous vouliez dire que vous l'avez ajouté à la liste des réclamations des clients et non à la liste des réclamations des utilisateurs? –

+0

Non, j'ai ajouté sur les revendications des utilisateurs – MJK

+0

Oh dans ce cas, le locataireId ne doit-il pas correspondre à quelque chose comme un ClientId sur le client ou quelque chose de similaire du côté client? Fondamentalement à travers le schéma je devrais être capable de créer l'utilisateur x, y, z pour le client 2 et seul l'utilisateur x est le propriétaire du client 2 –