applications pratiques pour les profils Navigateur / POST et Navigateur / artefact SAML

Question

Je propose l'utilisation de SAML 1.1 comme la technologie pour prouver Web SSO dans un environnement client, et on m'a demandé quelque chose d'intéressant:

Quel profil scénario Navigateur / POST est approprié, et quels scénarios Navigateur / profil d'artefact de SAML est appropriée?

En fait, SAML 1.1 Spécifications de ne pas parler de la meilleure ni scénario le plus approprié pour les deux profils du navigateur.

Peut-être que les menaces de sécurité de chacun peut être utilisé pour ramasser les meilleurs. Dans ma vision, les deux peuvent être applyed également dans tout scénario à ce jour.

* Remarque:. La solution utilise Weblogic Server 10.0 et son soutien à SAML 1.1

Answer 1

Il me semblait que les deux profils offrent des niveaux de sécurité similaires. Avec le profil POST, l'utilisateur doit lancer explicitement le POST. Cela pourrait aider à contrecarrer quelque chose le long des lignes d'une attaque CSRF, mais je ne connais pas d'exploits réels. Le profil d'artefact, avec l'utilisation de la méthode GET, peut fournir une expérience plus transparente pour l'utilisateur.

Pour moi, l'inconvénient du profil d'artefact est la complexité dans l'ouverture du canal arrière. Mon serveur d'application consacre un fil à traiter la demande de l'utilisateur, et si ce thread est bloqué (en attente de l'arrière-canal IO pour terminer) pour très longtemps, le serveur d'application commence à exécuter très mal. Ainsi, la communication en arrière-canal doit être effectué très soigneusement pour assurer que les temps après une période de temps définie.

Même alors, si le IdP est vers le bas des problèmes, ce n'est pas aussi évident à mes utilisateurs que la faute est à l'IdP. Avec un profil POST, si l'IdP se conduit mal, les utilisateurs sont moins susceptibles de me blâmer.

Answer 2

En termes de sécurité, la principale différence est que, avec le profil POST, la réponse SAML (contenant l'affirmation) transite par le navigateur de l'utilisateur final, il doit y avoir au moins signé, et peut-être chiffré, s'il y a quelque chose que vous ne veulent pouvoir voir l'utilisateur final.

Avec le profil d'artefact, vous pouvez utiliser SSL pour sécuriser le canal arrière et envoyer une affirmation non signée, non chiffré, puisqu'il est passé directement du IdP à la SP. Vous pouvez encore signer l'affirmation de la non-répudiation, cependant.

Erickson mentionne, cependant, la mise en place de la connexion « canal arrière » sortant de la SP à l'IdP est livré avec ses propres défis. La plupart des déploiements SAML j'ai vu utiliser POST pour cette raison.

BTW - quelque raison que vous utilisez SAML 1.1 plutôt que 2.0