Блог

Главная - Вопросы по программированию - Azure AD SAML использует общий сертификат вместо конкретного приложения

Azure AD SAML использует общий сертификат вместо конкретного приложения

#azure #azure-active-directory #saml

Вопрос:

Поэтому мои наблюдения и ожидания заключаются в том, что при настройке приложения для единого входа будет использоваться сертификат для этого конкретного приложения.

Однако у меня есть несколько уже зарегистрированных приложений, которые не используют эти сертификаты, а скорее подписывают утверждение одним из сертификатов из общих метаданных. Мой вопрос: есть ли способ настроить такое поведение? Я попытался имитировать конфигурацию в новом приложении, но не смог добиться такого же поведения.

Что я заметил о конфигурации этих приложений:

  • Все они в какой — то момент «поговорили» с ADFS, а также использовали WS-FED (это цель здесь).
  • Даже если я попытаюсь получить доступ к приложению через MyApps и не получу ответа «ничего», подпись будет с общим сертификатом.
  • Я считаю, что все они используют прокси-сервер приложений (с предварительной авторизацией Azure AD).
  • Похоже, у них есть теги (8adf8e6e-67b2-4cf2-a259-e3dc5476 c621, windowsazureactivedirectorygalleryapplicationnprimaryv1), которые я не получаю при создании нового приложения SAML.

Вот как выглядит это утверждение:

 <samlp:Response ID="RESPONSEID_REPLACED" Version="2.0" IssueInstant="2021-10-11T17:47:30.259Z" Destination="https://127.0.0.1:444/applications/default.aspx" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/TENANT-ID-REPLACED/</Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <Assertion ID="ASSERTION_ID" IssueInstant="2021-10-11T17:47:30.243Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
        <Issuer>https://sts.windows.net/TENANT-ID-REPLACED/</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/2001/04/xmldsig-more#rsa-sha256"/>
                <Reference URI="#REFERENCE_URI_GUID_REPLACED">
                    <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/2001/04/xmlenc#sha256"/>
                    <DigestValue>Zvoq VZQsM eW9HzHcYSJQvSm7L6E5urRYKQehkJf7w=</DigestValue>
                </Reference>
            </SignedInfo>
            <SignatureValue>LONG_SIGNATURE_REPLACED</SignatureValue>
            <KeyInfo>
                <X509Data>
                    <X509Certificate>MIIDBTCCAe2gAwIBAgIQWPB1ofOpA7FFlOBk5iPaNTANBgkqhkiG9w0BAQsFADAtMSswKQYDVQQDEyJhY2NvdW50cy5hY2Nlc3Njb250cm9sLndpbmRvd3MubmV0MB4XDTIxMDIwNzE3MDAzOVoXDTI2MDIwNjE3MDAzOVowLTErMCkGA1UEAxMiYWNjb3VudHMuYWNjZXNzY29udHJvbC53aW5kb3dzLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALH7FzF1rjvnZ4i2iBC2tz8qs/WP61n3/wFawgJxUnTx2vP/z5pG7f8qvumd7taOII0aSlp648SIfMw59WdUUtup5CnDYOcX1sUdivAj20m2PIDK6f KWZ 7YKxJqCzJMH4GGlQvuDIhRKNT9oHfZgnYCCAmjXmJBtWyD052qqrkzOSn0/e9TKbjlTnTNcrIno3XDQ7xG 79vOD2GZMNopsKogWNxUdLFRu44ClKLRb4Xe00eVrANtBkv mSJFFJS1Gxv611hpdGI2S0v1H KvB26O7vuzGhZ/AevRemGhXQ5V5vwNEqXnVRVkBRszLKeN/ rxM436xQyVQGJMG sVECAwEAAaMhMB8wHQYDVR0OBBYEFLlRBSxxgmNPObCFrl hSsbcvRkcMA0GCSqGSIb3DQEBCwUAA4IBAQB UQFTNs6BUY3AIGkS2ZRuZgJsNEr/ZEM4aCs2domd2Oqj7 5iWsnPh5CugFnI4nd ZLgKVHSD6acQ27we eNY6gxfpQCY1fiN/uKOOsA0If8IbPdBEhtPerRgPJFXLHaYVqD8UYDo5KNCcoB4Kh8nvCWRGPUUHPRqp7AnAcVrcbiXA/bmMCnFWuNNahcaAKiJTxYlKDaDIiPN35yECYbDj0PBWJUxobrvj5I275jbikkp8QSLYnSU/v7dMDUbxSLfZ7zsTuaF2Qx L62PsYTwLzIFX3M8EMSQ6h68TupFTi5n0M2yIXQgoRoNEDWNJZ/aZMY/gqT02GQGBWrh /vJ</X509Certificate>
                </X509Data>
            </KeyInfo>
        </Signature>

Комментарии:

1. о каком сертификате вы говорите — о подписи или шифровании? Сертификат подписи обычно является общим для всех RP, в то время как сертификат шифрования определяется соответствующим RP во время обмена метаданными федерации.

2. Добавлен код в качестве примера. Эта подпись обычно берется из сертификата конкретного приложения, но в данном случае она показывает сертификат из общих метаданных.

3. Сертификат подписи, специфичный для RP, используется для проверки подписи запроса SAML, отправленного RP. Он не используется для подписи SAMLResponse, сгенерированного ADFS. Общий сертификат подписи используется ADFS для подписи SAMLResponse (утверждения) для всех RPS. Я думаю, что поведение, которое вы наблюдаете, соответствует ожиданиям.

4. Но это не является последовательным. Некоторые приложения делают это, некоторые-нет. ADFS здесь не обязательно является фактором… Лазурный-это. Ответ отправляется из Azure, и некоторые приложения подписаны с помощью accounts.accesscontrol-cert, а некоторые-с помощью объединенного сертификата единого входа Azure AD.

Ответ №1:

Похоже, это ошибка/странная ситуация. Я ошибся в одной детали; на самом деле использовался сертификат, который был в корпоративном приложении..

Однако сертификат по умолчанию для вновь созданного приложения, не относящегося к галерее или приложению approxy , по умолчанию будет иметь общедоступный сертификат Azure (отпечаток 977B10FB9D1C087E3105564B1D31B09D247BEBCD пальца, тема accounts.accesscontrol.windows.net ).

При редактировании конфигурации единого входа этот сертификат, похоже, обновляется, но для некоторых моих приложений он, похоже, отсутствует… Таким образом, он все еще подписывался сертификатом Azure AD по умолчанию.

Метки: