J'ai un STS qui enregistre des personnes, génère un tas de revendications, les charge dans l'identité et donc le principal, et transfère le contrôle à mon application de portail. Le portail peut voir toutes les revendications via Thread.CurrentPrinciple.Identities. Dans une circonstance, le portail modifie deux des revendications. Après cela, d'autres méthodes dans le portail peuvent voir les revendications mises à jour via le même mécanisme décrit ci-dessus. Cependant, si je transfère le contrôle au STS, il voit les revendications originales, pas celles qui ont été modifiées, à nouveau via Thread.CurrentPrinciple.Identities. Quelqu'un peut-il voir ce que je fais mal? Je ne peux pas comprendre pourquoi il y aurait une différence ... Je pensais que le principal était lié à la session et vu la même chose par le STS et les parties de confiance. Thanks-WIF: revendications mises à jour non vues par d'autres processus
0
A
Répondre
0
Le STS et le portail (alias party) ont tous deux des cookies distincts et des ensembles de revendications distincts. Lorsque vous revenez du portail/rp vers le STS et affichez son identité, vous voyez les revendications STS qui ont été ajoutées à son cookie local (générées lors de votre première connexion au STS). Lorsque vous naviguez vers le portail, vous voyez les revendications dans le cookie de ce site (générées lorsque le STS a d'abord envoyé un jeton WIF et que le module du portail l'a intercepté). Par conséquent, si vous modifiez des revendications dans le portail, elles n'affecteront pas les revendications dans le cookie STS.
Ah oui. Merci pour ça! Savez-vous s'il existe une convention pour la préservation des informations à l'échelle de la session? Je pensais que le cookie était universel, pour ainsi dire. Si ce n'est pas le cas, j'ai besoin de quelque chose qui est, et il doit être sécurisé. – rdgWarren
Si vous aviez un cookie universel, il deviendrait rapidement non évolutif car votre nombre de revendications à l'intérieur augmenterait et grandirait à mesure que vous ajouteriez de nouveaux sites à votre système de connexion unique. Un meilleur schéma consiste pour le STS à émettre un petit nombre de revendications génériques à chaque RP lorsqu'il envoie pour la première fois le jeton WIF au RP. Ensuite, chacun de vos RP doit enrichir ce jeton avec ses propres revendications spécifiques au domaine. Ils peuvent le faire via le ClaimsAuthenticationManager ... – jonho
..Si vous voulez que les changements d'état effectués dans un RP soient accessibles dans le STS, je sauvegarderais probablement l'état dans la base de données du RP et j'implémenterais un service web autour d'elle. Ensuite, lorsque vous revenez dans le STS, appelez le service Web. Vous pourriez avoir une base de données d'état centrale, mais cela laisse échapper des connaissances sur le domaine de vos sites fédérés, ce qui n'est pas très agréable. – jonho