ADFS idpinitiatedsignon Утверждение SAML не подписано - PullRequest
Новая
       97

ADFS idpinitiatedsignon Утверждение SAML не подписано

0 голосов
/ 12 марта 2020

Я пытаюсь извлечь утверждение SAMLResponse через https://<adfs_domain>/adfs/ls/idpinitiatedsignon с помощью веб-просмотра. Проблема заключается в том, что утверждение SAMLResponse не подписано, а подпись не включена в утверждение.

В результате я не могу проверить утверждение SAML. Мы настроили ADFS с сертификатом подписи ADFS, так как это поток, инициированный IDP.

Также мы устанавливаем следующее свойство в ADFS: SamlResponseSignature = AssertionOnly

<samlp:Response ID="_255ada50-94a5-493a-9234-0e9801f0a994" Version="2.0" IssueInstant="2020-03-09T13:27:11.297Z" Destination="https://mobile_app/login" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" 
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://adfs_domain/adfs/services/trust</Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
  </samlp:Status>
  <Assertion ID="_0d711b58-e28a-4315-976d-5a4ec6abb3ab" IssueInstant="2020-03-09T13:27:11.297Z" Version="2.0" 
    xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>http://adfs_domain/adfs/services/trust</Issuer>
    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">test_user@domain.com</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData NotOnOrAfter="2020-03-09T13:32:11.297Z" Recipient="https://mobile_app/login" />
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2020-03-09T13:27:11.297Z" NotOnOrAfter="2020-03-09T14:27:11.297Z">
      <AudienceRestriction>
        <Audience>https://doamin/mobile/platform/sso/exchange-token</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <Attribute Name="http://schemas.xmlsoap.org/claims/CommonName">
        <AttributeValue>test_user@domain.com</AttributeValue>
      </Attribute>
      <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
        <AttributeValue>test_user@domain.com</AttributeValue>
      </Attribute>
      <Attribute Name="http://schemas.xmlsoap.org/claims/Group">
        <AttributeValue>Domain Users</AttributeValue>
      </Attribute>
    </AttributeStatement>
    <AuthnStatement AuthnInstant="2020-03-09T13:27:11.155Z" SessionIndex="_0d711b58-e28a-4315-976d-5a4ec6abb3ab">
      <AuthnContext>
        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
  </Assertion>
</samlp:Response>

1 Ответ

1 голос
/ 14 марта 2020

Я очень сомневаюсь, что вы получаете неподписанное утверждение. Вы всегда должны получать токен, подписанный с использованием сертификата подписи токена сервера AD FS, независимо от того, предоставляете ли вы сертификат, позволяющий AD FS проверять любые подписанные запросы, отправляемые вашим приложением в AD FS.

Сведения о сертификате вы должны увидеть в метаданных федерации, опубликованных по адресу https://adfs_fqdn / federationmetadata / 2007-06 / federationmetadata. xml. Вы можете использовать https://adfshelp.microsoft.com/MetadataExplorer/ShowFederationMetadata для более удобного просмотра опубликованных сведений.

Вы можете проверить, какова полезная нагрузка, возвращаемая AD FS, используя что-то вроде https://adfshelp.microsoft.com/ClaimsXray/TokenRequest. Затем вы можете отправить вход в SAML, который будет использовать инициированный idp поток, и вы увидите необработанную полезную нагрузку, возвращаемую AD FS. Затем вы можете переключать SamlResponseSignature по своему усмотрению и видеть возвращаемые токены.

...