2017-08-25 9 views
0

J'utilise l'option WS Federation dans AD FS pour que les utilisateurs se connectent à notre site Web (WebsiteA). Maintenant, nous devons faire un SSO à un autre fournisseur ... disons WebsiteB.Jeton d'actualisation AD FS avant IdpInitiatedLogin SSO

Pour faire SSO je viens de lancer IdpInitiatedLogin via mon AD FS et l'utilisateur se connecte à WebsiteB.

L'utilisateur a généralement 2 comptes dans WebsiteB par compte dans WebsiteA. Pour vous connecter à un compte sur WebsiteB, nous définissons une propriété dans LDS à partir de WebsiteA avant IdpInitiatedLogin. Cela définit une réclamation pour WebsiteB, de sorte qu'il sait quel compte utiliser. Le problème est que lorsque nous définissons des valeurs différentes dans la même propriété dans LDS, il ne sera pas actualisé dans les informations de revendication pour SAML, comme indiqué par siteB.

Est-il possible d'actualiser les informations SAML/Token ou revendications avant le processus IdpInitiatedLogin afin que l'utilisateur se connecte au compte correct?

+0

Je n'ai pas beaucoup de pratique dans la région, donc je ne fais que jeter des idées qui ne sont peut-être pas très bonnes, et donc ce n'est qu'un commentaire ... mais je crois que les jetons SAML sont essentiellement des cookies. Si vous pouvez effacer le cookie, cela actualisera effectivement le jeton. Mais surtout, je pense que ce que vous voulez faire n'est pas bien supporté par SAML. Je vois ceci, où je gère un domaine Google Apps pour un petit collège, et il est difficile de permettre à un membre du personnel d'être connecté à deux comptes Google SSO en même temps. Je demande généralement aux gens qui ont besoin de faire cela d'utiliser deux navigateurs différents. –

+0

Merci Joel, Enfait quand je vois dans les cookies il n'y a aucun cadeau de cookies qui appartient à SAML. Cependant, je comprends votre point, mais même rafraîchir ne fonctionne pas. Totalement perdu dans cette zone particulière! –

Répondre

0

Merci Joel Coehoorn, nzpcmad pour avoir regardé le problème auquel je faisais face. Après avoir fait de nombreuses recherches sur le sujet, je n'ai pas trouvé beaucoup de références pointant vers ce sujet.

Selon ma compréhension, le problème est avec la mise en cache des propriétés comme une fois que vous gets connecté.

Pour résoudre le problème, je l'ai utilisé Attributs personnalisés magasin (en utilisant la base de données SQL). Il interroge la base de données chaque fois que vous lancez un IDPInitiatedSignIn. Ou dites chaque fois qu'il envoie cette réclamation (Utilisation de réclamation personnalisée).

Pour les autres développeurs comme moi, qui peuvent faire face au même problème, je poste ma solution ici. J'espère que ça aide :)

1

Les revendications ne sont pas dynamiques.

Vous devez vous déconnecter/vous connecter pour les rafraîchir.

Vous pouvez le faire par programmation - voir https://social.technet.microsoft.com/wiki/contents/articles/1439.ad-fs-how-to-invoke-a-ws-federation-sign-out.aspx

Mise à jour

Vous devez vous connecter manuellement.

Si vos attributs AD changent si souvent, les revendications ne sont pas la meilleure solution. Vous devriez obtenir les attributs de AD via les services Directory de C#, etc.

+0

Merci nzpcmad, L'article m'a donné une bonne connaissance sur le processus de déconnexion. Mais il n'a pas mentionné comment peut-on se déconnecter et se connecter à cet utilisateur par programmation? –

+0

Vous devez appuyer sur cette URL. – nzpcmad

+0

Ok, je l'ai fait et ça m'a tout simplement déconnecté. Comment puis-je me connecter à la même utilisation sans demander d'informations d'identification? –