Блог

Нам нужно настроить ADFS в качестве поставщика услуг. Итак, мы попытались отправить ответ saml в ADFS. Мы настроили заглушки для поставщика утверждений, RPT и создали сертификаты. Мы пытаемся отправить saml в adfs / ls /IdpinitiatedSignon.aspx с RelayState.

Вот пример ответа Saml.

 <samlp:Response ID="_6bcc31a5-fcc2-46a6-a84d-0df2cb5bed17" Version="2.0" IssueInstant="2019-03-27T12:37:34.839Z" Destination="https://srv2012-test-dc.testdomain.com/adfs/ls/idpinitiatedsignon.aspx" InResponseTo="_728ac076-7b14-4ce2-8efb-ed5c8c9b85f3" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">anthem.cn.com</Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <Assertion ID="_eeaaab87-0fcc-4ec1-93d3-ed623b27130c" IssueInstant="2019-03-27T12:37:41.843Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
        <Issuer>anthem.cn.com</Issuer>
        <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
            <SignedInfo>
                <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                <Reference URI="#_eeaaab87-0fcc-4ec1-93d3-ed623b27130c">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue>MkByT8QpjpBFszlr74Rx0IZNewk=</DigestValue>
                </Reference>
            </SignedInfo>
            <SignatureValue>AYhBtCEl4CrsgsuWMaLEDP...</SignatureValue>
            <KeyInfo>
                <X509Data>
                    <X509Certificate>MII...</X509Certificate>
                </X509Data>
            </KeyInfo>
        </Signature>
        <Subject>
            <NameID>VALERA</NameID>
            <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <SubjectConfirmationData InResponseTo="_728ac076-7b14-4ce2-8efb-ed5c8c9b85f3" NotBefore="2019-03-27T12:32:34.839Z" NotOnOrAfter="2019-03-27T13:37:34.847Z"/>
            </SubjectConfirmation>
        </Subject>
        <Conditions>
            <AudienceRestriction>
                <Audience>https://beta3dev.test.com/</Audience>
            </AudienceRestriction>
        </Conditions>
        <AuthnStatement AuthnInstant="2019-03-27T12:37:41.843Z" SessionIndex="_56b775bf-32a7-4f35-a370-d707a653a5aa">
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
        <AttributeStatement>
            <Attribute Name="FirstName">
                <AttributeValue>valera</AttributeValue>
            </Attribute>
        </AttributeStatement>
    </Assertion>
</samlp:Response>
  

Кажется, он действителен, мы проверили онлайн-валидаторы, но ADFS выдает исключение:

Майкрософт.Исключение IdentityServer.Web.UnsupportedSamlResponseException: MSIS7029: ответ SAML содержит содержимое, которое не поддерживается.

Итак, вопрос в следующем: что не так с saml?

P.S. На самом деле, мы не знаем, как работает сценарий, инициированный idp. Возможно, существует какой-то минимальный набор утверждений или мы не можем войти, потому что у нас нет рабочих заглушек. Было бы неплохо получить дополнительную информацию об этом потоке данных.

Хорошо, теперь это работает.

1. В сценарии, инициированном IdP, нет запроса, поэтому мы удалили все атрибуты InResponseTo.
2. AuthnContext изменен на PasswordProtectedTransport.

Идентификатор имени может быть включен, но не должно быть атрибута NotBefore.