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

Я пытаюсь извлечь утверждение 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">[email protected]</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>[email protected]</AttributeValue>
      </Attribute>
      <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
        <AttributeValue>[email protected]</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>

active-directory adfs adfs3.0
person KALALEX    schedule 12.03.2020    source источник
comment
Привет @KALALEX, ты нашел для этого решение? в моем случае запрос подписан, а утверждение нет!   -  person Bhushan Karmarkar    schedule 02.02.2021

Ответы (1)


arrow_upward
1
arrow_downward

Я очень сомневаюсь, что вы получаете неподписанное утверждение. Вы всегда должны получать токен, подписанный с помощью сертификата подписи токена сервера 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 по своему усмотрению и увидеть возвращенные токены.

person maweeras    schedule 14.03.2020
comment
Похоже, для этого требуется подписанный запрос SAML, даже если он нигде не задокументирован, насколько я видел, я могу ошибаться. - person KALALEX; 15.04.2020