assertion SAML avec nom d'utilisateur / mot de passe - qu'est-ce que les messages ressemblent vraiment?

Question

Je dois créer une des assertions SAML 2.0, et je vais avoir du mal à trouver ce qui devrait vraiment regarder comme le XML. La plupart des documents semble être sur l'utilisation des outils particuliers, pas les messages. J'ai les schémas, avec une pléthore de possibilités, mais je ne peux pas trouver un exemple de ce que les messages pertinents ressemblent vraiment dans la pratique.

La règle d'affaires dit: afin de créer une identité partagée, l'utilisateur indique le système A leur nom d'utilisateur et mot de passe sur le système B. Système A doit communiquer cette information (ainsi que certaines caractéristiques démographiques) au système B. Système B valide la informations et passe en arrière un identifiant unique qui peut ensuite être utilisé pour faire référence à cet utilisateur.

Quelqu'un pourrait-il me donner un exemple de ce que les assertions SAML 2.0 ressembleraient à porter cette information?

FWIW, j'utilise C #, et la nécessité de passer le XML autour d'une manière qui empêche l'aide d'un outil 3ème partie.

Answer 1

Je ne suis pas sûr que votre cas d'utilisation est tout à fait ce que fait SAML 2.0.

Ce que vous décrivez que vos règles d'affaires ressemble vraiment à un cas d'utilisation pour le provisionnement d'identité, accès non gestion.

standard SAML 2.0 cas d'utilisation se concentrent sur une partie affirmation de l'identité (le fournisseur d'identité) et l'autre partie (ou parties) se fondant sur ces affirmations (le fournisseur de services). Assertions portent ce qu'on appelle un identifiant de nom, dont l'utilisation est convenu à l'avance entre le fournisseur d'identité et le fournisseur de services.

Ces identifiants de nom peut être à peu près tout, mais ils tombent en deux grandes catégories: transitoires et persistants. Un identifiant de nom transitoire est utile dans le cadre de la session en cours (et dit essentiellement que: « Je sais qui est cette personne ») et a tendance à être utilisé pour protéger l'identité du principal tout en permettant un accès privilégié d'un certain type. Un identifiant persistant peut être soit opaque (d'une manière similaire à la façon dont OpenID est utilisé pour accéder SO) où la partie qui affirme peut vérifier à plusieurs reprises l'identité d'un principe sans révéler leur identité tout en maintenant un identifiant partagé dynamique mais stable entre les partis assertive et en comptant ou plus importante, comme un active Directory UPN (qui peut être à l'avance convenu à l'avance).

En ce qui concerne les mots de passe, comme vous le mentionnez dans votre question, le fournisseur de services (partie utilisatrice) ne voit jamais le mot de passe de l'utilisateur. Le fournisseur de services remet l'utilisateur vers le fournisseur d'identité avec une demande d'authentification. Le fournisseur d'identité envoie à l'utilisateur au fournisseur de services avec une réponse qui, dans le cas d'authentification réussie contient une affirmation sur l'identité de l'utilisateur dans le contexte de la relation entre le fournisseur d'identité et le fournisseur de services.

Dans le contexte de votre question, la grande chose est que SAML 2.0 ne fournit pas un moyen de créer soit le compte utilisateur « application » locale ou un lien qui compte utilisateur local à une identité fédérée. Ceci est tout simplement pas le problème SAML 2.0 tente de résoudre.

Maintenant, retour à vos règles d'affaires ...

Il me semble que ce que vous essayez de faire est soit l'association des comptes ou de l'enregistrement - Je l'approche comme ceci:

• application visites de l'utilisateur, clique sur un bouton pour utiliser l'identité du fournisseur d'identité
• L'application produit une demande d'authentification et dirige l'utilisateur vers le fournisseur d'identité, portant cette demande d'authentification
• Le fournisseur d'identité soit dans les journaux ou l'utilisateur réutilise une session d'identité existant si l'utilisateur a un. Le IdP produit un message de réponse contenant une assertion sur l'utilisateur. Dans votre cas, cette affirmation devrait au minimum porter un identifiant de nom persistant. Le fournisseur d'identité dirige l'utilisateur à l'application, portant le message de réponse.
• L'application traite le message de réponse. Si une entrée de mappage existe pour l'identifiant persistant transmis à l'utilisateur est reconnu à partir de cette cartographie et connecté en tant que utilisateur de l'application locale. Si aucune entrée de mappage existe, l'utilisateur peut être invité à se connecter localement et lors de la connexion locale avec succès l'entrée de mappage peut être produit, ou un compte d'utilisateur peut être créé automatiquement et pourrait être demandé à l'utilisateur de saisir des informations supplémentaires (noms, adresses e-mail , etc.) le cas d'utilisation « corporate » serait qu'aucun compte chaînage automatique ou la création est autorisée et que la cartographie doit exister à l'avance.

En ce qui concerne le contenu des messages ...

Le Comité technique OASIS Services de sécurité a un fichier zip téléchargement disponible avec une documentation complète des parties du schéma XML, y compris des exemples. Il est également bien utile de lire le protocole et la documentation profil, car ceux-ci décrivent le flux de messages entreles parties impliquées dans la conversation d'identité.

Il existe un grand nombre de présentations flottant autour que j'ai trouvé très utile. Plus précisément, Principes de base v2.0 SAML par Eve Maler m'a aidé à commencer à réaliser ce que les problèmes v2.0 SAML tente de résoudre. Cette présentation comprend des exemples de cette affirmations ressemblent. Il y a une présentation mise à jour et des liens vers des ressources supplémentaires sur saml.xml.org .

Je ne sais pas si tout cela va aider si, comme votre cas d'utilisation ne semble pas être ce que SAML 2.0 essaie de faire. Vous pouvez ajouter des attributs et des extensions en fonction des besoins et des réponses aux demandes, mais je ne vois pas beaucoup de fournisseurs d'identité faire quelque chose avec ces attributs et les réponses.