2017-09-28 5 views
1

ContexteMS Azure B2C AD comme SAML IDP ne fonctionne pas

J'ai une application dans laquelle les utilisateurs inscrits/signer par B2C AD. Dans l'application, il y a un lien qui redirigera vers une autre application qui fonctionne sur SAML, de sorte que MS Azure fonctionne comme IDP et envoie SAML à la troisième application.

Nous l'avons atteint dans AAD (pas AD B2C) grâce à l'application non-galerie, mais des problèmes dans AD B2C.

Nous avons suivi ce document https://github.com/Azure-Samples/active-directory-b2c-advanced-policies/blob/master/Walkthroughs/RP-SAML.md mais lorsque nous avons tapé l'URL, il est écrit "AADB2C: Une exception s'est produite".

fichier de base - https://www.dropbox.com/s/ro6arbs57c43el2/base.xml?dl=0

fichier d'extension - https://www.dropbox.com/s/uqojtk432b3wny1/base_Extensions.xml?dl=0

fichier SignInSaml - https://www.dropbox.com/s/i950s4bwwagry5k/signinsaml.xml?dl=0

+0

[vous avez activé la journalisation?] (https://docs.microsoft.com/en-us/azure/active- répertoire-b2c/dossier-actif-b2c -troubleshoot-custom) – spottedmahn

+0

Je ne peux pas, je n'ai pas accès à ça. –

+0

Ajoutez un point de terminaison d'enregistreur de voyage à votre stratégie, soit des informations sur les applications, soit vous pouvez télécharger le point de terminaison de l'enregistreur de trajet avec les exemples de stratégies et déployer vers Azure – user1197563

Répondre

0

La meilleure chose que vous pouvez faire est de travailler avec OIDC d'abord et confirmer que la politique fonctionne, puis remplacer l'étape où vous émettez un jeton JWT avec SAML

Lorsque je travaille avec SAML j'ai ce format

Base de Base-extensions (si vous le voulez - je tendance à ne pas) politique OIDC (Ceci étend la base) politique SAML (Cela va OIDC)

Dans le SAML politique que je puis passer outre mon utilisateur étape orchestration de voyage qui appelle le JWTIssuer et ensuite appeler mon créateur de jeton SAML

La raison de cette approche est B2C a été conçu pour fonctionner avec OIDC, vous pouvez confirmer que le voyage fonctionne comme prévu dans OIDC, puis passez à votre SAML

Id également utiliser l'enregistreur de voyage, je trouve l'ancien journal B2C enregistreur ey vous obtenez mieux que des idées d'applications, mais à la fois suivre les mêmes données

Après avoir vérifié mon SAML au bureau de votre manque quelques métadonnée de dire SAML comment se comporter dans votre politique

 <Metadata> 
    <Item Key="IdpInitiatedProfileEnabled">true</Item> 
    <Item Key="RequestsSigned">false</Item> 
    <Item Key="WantsSignedResponses">true</Item> 
    <Item Key="ResponsesSigned">true</Item> 
    <Item Key="AssertionsEncrypted">false</Item> 
    <Item Key="WantsEncryptedAssertions">false</Item> 
    <Item Key="PartnerEntity">https://my-calling-application/authservices</Item> 
    </Metadata> 
    <SubjectNamingInfo ClaimType="UserId" /> 

Votre SubjectNamingInfo sera également doivent être http://schemas.microsoft.com/identity/claims/userprincipalname

comme cela est le nom SAAML que vous avez défini dans votre politique de base

+0

J'ai trouvé la solution du problème ci-dessus. Mais maintenant, quand Azure envoie la réponse SAML, il inclut l'attribut "InResponseTo" qui ne devrait pas être présent puisqu'il est initié par SAML. Avez-vous une idée à ce sujet? –