2011-07-22 2 views
1

J'ai un STS personnalisé construit avec WIF. Si j'ai le Relying Party et STS sur le même serveur, je peux le faire fonctionner. Cependant, je reçois des erreurs ID4036 lors de l'utilisation d'une machine distante. Comme je l'ai creusé, j'ai trouvé que par défaut dans mon STS était toujours encryptage le jeton sortant avec un certificat local plutôt que le certificat demandé par la partie utilisatrice. Une solution consisterait à installer le certificat utilisé par la partie utilisatrice (clé publique uniquement) sur le STS et à coder le STS pour utiliser ce certificat.Est-ce que STS a besoin du certificat RP installé?

Cependant, cela crée un problème car j'ajoute d'autres parties utilisatrices sur différents serveurs.

Voici un exemple:

STS sur Mysts - signes jetons avec SigningCert.

partie utilisatrice sur MyWebServer01 - veut crypter/décrypter avec MyWebServer01Cert (propriétaire clé publique/privée)

Je peux installer MyWebServer01Cert sur Mysts et définir les STS à utiliser pour chiffrer les jetons, et tout devrait fonctionner. Cependant, disons que je veux ajouter une application de confiance à MyWebServer02. Cela ne fonctionnera pas à moins que j'installe la clé publique et privée de MyWebServer01Cert.

Je pense que vous pouvez simplement transmettre la clé publique à la STS et chaque RP peut utiliser son propre - un peu comme SSL. Ce n'est pas le cas?

Toute aide/suggestion serait appréciée.

Répondre

1

Tout d'abord, pour le cryptage, seule la clé publique est nécessaire. En fait, vous ne voulez jamais donner la clé privée d'un certificat. Si vous utilisez le protocole WS Federation (généralement utilisé pour les scénarios STS sur des sites Web), la requête au STS n'est pas envoyée par votre serveur RP, mais par le navigateur de l'utilisateur. Je doute que vous appelez dire au navigateur d'utiliser la clé publique du site précédent pour la communication sur https. Le jeton crypté est en revanche déchiffré par le serveur rp (ce qui signifie que le serveur RP doit connaître la clé privée du certificat utilisé pour crypter le jeton). Compte tenu de ces circonstances, je suis à peu près certain que la clé publique du certificat du RP doit être présente sur le STS et ne peut être incluse dans la demande. Tout le reste serait probablement un hack sale fonctionnant uniquement avec votre STS personnalisé (par exemple en incluant la clé publique comme paramètre).

Au moins pour les scénarios de "connexion passive". Pour WCF vous pouvez attacher le certificat de votre serveur en tant que certificat client à votre demande. Mais je n'ai pas essayé par moi-même.

+0

Merci, je crois que vous avez raison également. J'ai d'autres problèmes, mais ils méritent probablement leur propre fil. –

Questions connexes