0
votes

Les ADFS ne transmettent pas de réclamations de la réponse de WS-Fed de fournisseur de réclamer à la réponse SAML sortante pour RP

Dans mon environnement Il existe un projet ADFS 4.0 et ASP.NET avec le package ItalyServer4 + WSFeDeration en tant que fournisseur de réclamation. Tous les RPS qui utilisent un protocole de protocole Fed WS. Mais SamLP RP, ne reçoit pas de réclamations dans la réponse.

séquençage: Le RP initie une demande SAML Signin dans les ADFS. ADFS fait une demande de Singin de WS-Fed à IdentityServer4. Les ADFS obtiennent une réponse à la Fed WS avec une revendication de propert. Mais à l'étape suivante, lorsque ADFS génère une réponse SAML de la réponse de la Fed WS-Fed, ADFS émet la réponse SAML pour RP sans revendications ... Il y a une erreur dans le journal des événements: p>

Epidit: 303: p>

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                ID="_59eef1fa-81c5-4ede-8538-6caf4dbdf480"
                Version="2.0"
                IssueInstant="2020-07-01T14:10:26.698Z"
                Destination="xxxxxxxxx/adfs/ls/"
                Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
                InResponseTo="id-7052d47f-3df0-4d49-8ddf-673603bccb8e"
                >
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">xxxxxxxx/adfs/services/trust</Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
            <ds:Reference URI="#_59eef1fa-81c5-4ede-8538-6caf4dbdf480">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                <ds:DigestValue>iia3AYaxxx8UoxILqjhsxkgeO4rXqPk9Jil1t0jUbLU=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>xxxxxxxx</ds:SignatureValue>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
            <ds:X509Data>
                <ds:X509Certificate>xxxxxxxxxxxxxxxxxx</ds:X509Certificate>
            </ds:X509Data>
        </KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" />
    </samlp:Status>
</samlp:Response>

asp.net-core saml adfs ws-federation

0 commentaires

3 Réponses :

0
votes

L'URN: Oasis: noms: TC: saml: 2.0: Statut: répondeur "est un statut d'erreur. La réponse SAML contiendra une affirmation SAML avec les différentes revendications que le sujet SAML et les attributs SAML uniquement en cas de succès.

Vérifiez le journal des événements Windows sur le serveur ADFS. Il y aura un ou plusieurs événements d'erreur associés à cette erreur. C'est probablement une sorte d'erreur de configuration.

2 commentaires

Le journal des événements Windows a une erreur: ID d'événement: 303. "MSIS7099: L'élément SubjectConfirmationData est manquant dans le jeton reçu." Des idées ce que cela pourrait être? Les ADF peuvent-ils obtenir une réponse de la Fed WS auprès du fournisseur de sinistres et émettre une réponse SAML 2.0 basée sur le message WS-Fed?

Merci beaucoup, votre réponse, a commencé ma recherche un problème réel. En fait, la raison de l'erreur était que IdentityServer4 génère un jeton SAML 2.0 à l'intérieur du message WSFedération par défaut au lieu de SAML 1.1. Tout a bien fonctionné jusqu'à ce que les applications ont lancé la demande de signature WSFeDeration et extrayez SAML Token, mais lorsque l'application a envoyé la demande de connexion SAML, les ADFS ont été extraites le jeton SAML mais ADFS fonctionne uniquement avec SAML 1.1. Donc, en tant que solution, je change la version de jeton SAML à 1,1 à IdenittServier4.

0
votes

On dirait que vous ne passez pas à travers les revendications.

Vous avez besoin de règles de passage sur le côté du CP de Fed WS et le même ensemble de règles de passage sur le côté SAML RP.

Étant donné que WS-Fed n'utilise pas NameID, vous devrez peut-être également convenir d'une revendication de nom du côté SAML à l'aide d'E.G. email ou upn.

0 commentaires

0
votes

L'erreur était que IdentityServer4 génère un jeton SAML 2.0 à l'intérieur du message WSFedération par défaut à la place de SAML 1.1. Tout fonctionnait bien jusqu'à ce que les applications ont lancé la demande de signature WSFeDeration et extrayez SAML Token, mais lorsque l'application a envoyé la demande SAML SingIN, les ADFS doivent extraire le jeton SAML mais ADFS fonctionne uniquement avec SAML 1.1. Ainsi, en tant que solution, j'ai commuté une version de jeton de SAML 2.0 à SAML 1.1 dans identityServer4 et tous ont commencé à travailler.

namespace IdentityServer4.WsFederation
{
    public class WsFederationOptions
    {
        //public string DefaultTokenType { get; set; } = WsFederationConstants.TokenTypes.Saml2TokenProfile11; // was
        public string DefaultTokenType { get; set; } = WsFederationConstants.TokenTypes.OasisWssSaml11TokenProfile11; // working way
       ...
    }
}

0 commentaires