2017-08-18 1 views
0

Nous avons plusieurs fournisseurs de services utilisant Saml 2.0 pour l'authentification unique et ils fonctionnent tous très bien. Notre ajout le plus récent est le recadrage parce que nous envoyons un attribut NotBefore sur l'élément SubjectConfirmationData. Pour autant que je peux dire, cela fait partie du schéma xsd pour Saml 2.0 (https://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd) mais il est marqué comme NE DOIT PAS dans ce profil PDF (https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf).Saml 2.0: Pourquoi NotBefore dans le schéma pour SubjectConfirmationData s'il n'est pas autorisé?

Qu'est-ce qui me manque?

Répondre

0

Comme vous l'avez compris, le profil SSO du navigateur Web, qui est celui que vous utilisez pour fournir une authentification unique à vos utilisateurs en tant que fournisseur d'identité, vous interdit de définir NotBefore. Le profil définit d'autres limitations pour le schéma défini pour l'assertion à utiliser de manière générique, ce qui est totalement correct.

Le fournisseur de services à portée de main vérifie strictement la conformité et rejette donc votre assertion. Le fait qu'il ait fonctionné jusqu'à présent signifie probablement que les autres implémentations du fournisseur de services étaient plus clémentes.

+0

Ma question est, pourquoi le conflit? Pourquoi l'avoir dans le schéma si vous n'êtes pas censé l'utiliser? – user34314

+0

Il n'y a pas de conflit. Le schéma définit comment l'assertion peut être structurée et différents profils définissent leurs propres limites. Comme vous pouvez le voir sur https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf, seul le profil SSO du navigateur Web définit cette limitation, donc 'NotBefore 'peut très bien être utilisé dans l'un des autres profils ici. –