3
Je travaille avec Azure ACS et l'incorpore dans une stratégie SSO pour mon site Web .NET 4.0. Je vois sur la page Groupes de règles qu'un certain nombre de revendications différentes peuvent être stockées et transmises au RP (par exemple, pays, adresse de rue, téléphone, etc.). Il semble que vous puissiez également renvoyer tout type de réclamation que vous souhaitez créer. Cela m'a fait réfléchir à de nombreuses questions relatives au stockage des informations pour les utilisateurs:Azure ACS et stocker des informations pour les utilisateurs sur elle vs local?
- Est-il sensé de stocker des informations utilisateur (autres que l'identificateur de nom) dans ACS par rapport aux tables de base de données locales?
- Il semblait que vous pouviez créer des groupes de règles illimités et des règles en leur sein. Est-ce exact?
- Je traiterais avec différentes entreprises et utilisateurs au sein de l'entreprise. Est-ce que créer un groupe de règles pour chaque entreprise et ensuite créer des règles pour chaque utilisateur serait un choix judicieux?
- Il semble que l'API est assez robuste et permettrait que cela soit fait automatiquement à la suite d'une page d'inscription, etc. Correct ou incorrect? Est-il possible et recommandé d'exécuter une requête contre ACS pour renvoyer des informations sur un utilisateur (par exemple, demander son adresse e-mail lorsqu'il est hors ligne pour lui envoyer un message à propos de quelque chose)
- Pourriez-vous recevoir des informations en masse? à des fins de reporting hors ACS?
Merci pour la bonne réponse! Une question que j'ai est sur l'environnement multi-locataires. J'aurais plusieurs utilisateurs de différentes sociétés en cliquant sur la même URL pour accéder à mon SaaS. J'avais l'impression qu'une partie utilisatrice était synonyme d'URL. En regardant l'exemple 7, j'imagine que le routage est activé dans mon application afin que les utilisateurs puissent tous taper http://www.robsite.com/{their company name} et que cela se traduise par ACS de cette façon? – Rob