SAML

SAML 기반 ID 제공자를 사용하는 경우 싱글 사인온(SSO) 경험을 시작하도록 App ID을(를) 구성할 수 있습니다. 이 유형의 흐름에서 App ID 는 서비스 제공자 역할을 하며 월간 활성 사용자(MAU)를 위한 보안 토큰을 제공합니다.

SAML 이해

SAML(Security Assertion Markup Language)은 ID를 어설션하는 제공자와 ID 정보를 사용하는 제공자 간에 인증 및 권한 부여 데이터를 교환하는 데 사용하는 개방형 표준입니다. SAML 2.0 는 XML을 기반으로 하며 인증 및 권한 부여 표준을 위해 잘 정립된 프레임워크입니다.

SAML 프로토콜은 App ID(서비스 제공자)와 ID 제공자 사이를 연결합니다. ID 제공자가 사용자를 인증하면 사용자에 대한 정보(예: 인증 방법, 연관된 속성 또는 권한 매개변수)를 포함하는 SAML 토큰이 생성됩니다. 다음 표에서 몇 가지 예제를 확인하십시오.

SAML 토큰에서 반환되는 정보 유형 이해하기
정보 유형 예제
인증 비밀번호, MFA 또는 다른 방법을 사용하여 사용자가 인증되었을 수 있습니다.
속성 속한 그룹 또는 환경 설정과 같은 모든 속성.
권한 부여 의사결정 경우에 따라 사용자에게 다른 사용자의 권한보다 많거나 적은 권한이 부여될 수 있습니다.

이 플로우의 형태는 어떻습니까?

SAML 프레임워크를 사용하여 사용자를 인증하지만, App ID에서는 여전히 더 현대적인 OIDC 프로토콜을 사용하여 애플리케이션과 보안 토큰을 교환합니다. 자세한 정보 플로우를 보려면 다음 이미지를 확인하십시오.

SAML 엔터프라이즈 인증 흐름 엔터프라이즈 인증 흐름의 작동 방식
SAML

  1. 사용자가 애플리케이션의 로그인 페이지 또는 제한된 리소스에 액세스하면 App ID SDK 또는 API를 통해 App ID /authorization 엔드포인트에 요청이 시작됩니다. 권한이 없는 사용자일 경우 App ID로 경로 재지정되면서 인증 플로우가 시작됩니다.
  2. App ID에서 SAML 인증 요청(AuthNRequest)을 생성하고 브라우저에서 사용자가 SAML ID 제공자로 자동 경로 재지정됩니다.
  3. ID 제공자가 SAML 요청을 구문 분석하고 사용자를 인증하며 해당 어설션을 사용하여 SAML 응답을 생성합니다.
  4. ID 제공자가 SAML 응답을 사용하여 사용자와 응답을 다시 App ID로 경로 재지정합니다.
  5. 인증에 성공하면 App ID에서 사용자의 권한 부여 및 인증을 나타내는 액세스 및 ID 토큰을 작성한 후 이를 앱에 리턴합니다. 인증에 실패하면 App ID에서 ID 제공자 오류 코드를 앱에 리턴합니다.
  6. 사용자에게 앱 또는 보호된 리소스에 대한 액세스 권한이 부여됩니다.

SSO에서 어떻게 플로우를 변경합니까?

SSO의 워크플로우는 비슷합니다. 설명된 워크플로우와의 차이점은 이전 섹션의 3단계뿐입니다. SSO가 사용 가능하면 사용자에게 인증을 요청하기 전에 사용자에게 이미 설정된 인증 세션이 있는지 ID 제공자가 확인합니다. 예이면 사용자에게 인증하도록 요청하지 않고 플로우가 정상적으로 지속됩니다. SSO 세션을 사용할 수 없으면 사용자의 경로가 사인인 페이지로 재지정됩니다. ID 제공자가 SSO를 설정하는 데 사용되는 요구사항과 App ID 요청에 정의된 인증 요구사항을 일치시킬 수 없는 경우 사용자가 경로 재지정될 수 있습니다. 예를 들어 ID 제공자가 생체인식을 사용하여 사용자 SSO 세션을 설정하는 경우, App ID의 기본 인증을 변경해야 합니다. 기본적으로 App ID에서는 사용자 인증이 HTTPS를 통해 비밀번호를 사용하여 수행될 것으로 예상합니다. urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport.

어설션 이해

SAML 어설션이 App ID에 리턴되면 서비스가 사용자 ID를 연합하고 해당 토큰을 생성합니다. SAML 어설션이 표준 OIDC 청구 중 하나에 해당하는 경우 자동으로 ID 토큰에 추가됩니다. 일치하지 않는 어설션은 기본적으로 무시됩니다. SAML 제공자가 다른 어설션을 리턴하면 토큰에 정보를 삽입하도록 App ID를 구성할 수 있습니다. 하지만 토큰은 일반적으로 HTTP 헤더로 전송되며 제한되어 있으므로 필요 이상의 정보를 추가하지 않도록 주의하세요.

표준 OIDC에서는 App ID에서 어설션에 맵핑을 시도하도록 요청합니다.

  • name
  • email
  • locale
  • picture

ID 제공자 측에서 해당 값 중 하나 이상이 변경되는 경우 사용자가 다시 로그인한 후 새 값을 사용할 수 있습니다.

App ID가 SAML 어설션의 형태를 어떻게 예상합니까?

서비스는 SAML 어설션의 형태가 다음 예제와 유사하다고 예상합니다.

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="s2202bbbbafa9d270d1c15990b738f4ab36139d463" InResponseTo="_e4a78780-35da-012e-8ea7-0050569200d8" Version="2.0" IssueInstant="2011-03-21T11:22:02Z" Destination="https://example.example.com/">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">idp_entityId</saml:Issuer>
  <samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <samlp:StatusCode  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="2.0" ID="pfx539c9774-de5c-5f52-0c3f-b1c2e2697a89" IssueInstant="2018-01-29T13:02:58Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer>idp_entityId</saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="one_of_supported_algo"/>
        <ds:SignatureMethod Algorithm="one_of_supported_algo"/>
        <ds:Reference URI="#pfx539c9774-de5c-5f52-0c3f-b1c2e2697a89">
          <ds:Transforms>
            <ds:Transform Algorithm="one_of_supported_algo"/>
            <ds:Transform Algorithm="one_of_supported_algo"/>
          </ds:Transforms>
          <ds:DigestMethod Algorithm="one_of_supported_algo"/>
          <ds:DigestValue>huywDPPfOEGyyzE7d5hjOG97p7FDdGrjoSfes6RB19g=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
 <ds:SignatureValue>BAwNZFgWF2oxD1ux0WPfeHnzL+IWYqGhkM9DD28nI9v8XtPN8tqmIb5y4bomaYknmNpWYn7TgNO2Rn/XOq+N9fTZXO2RybaC49iF+zWibRIcNwFKCCpDL6H6jA5eqJX2YKBR+K6Yt2JPoUIRLmqdgm2lMr4Nwq1KYcSzQ/yoV5W0SN/V5t8EfctFoaXVPdtfHVXkwqHeufo+L4gobFt9NRTzXB0SQEClA1L8hQ+/LhY4l46k1D0c34iWjVLZr+ecQyubf7rekOG/R7DjWCFMTke822dR+eJTPWFsHGSPWCDDHFYqB4QMinTvUnsngjY3AssPqIOjeUxjL3p+GXn8IQ==</ds:SignatureValue>
    </ds:Signature>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">JohnDoe@gmail.com</saml:NameID>
    </saml:Subject>
    <saml:Conditions NotBefore="2018-01-29T12:59:58Z" NotOnOrAfter="2018-01-29T13:05:58Z">
    </saml:Conditions>
</samlp:Response>

App ID에서 지원되는 알고리즘의 유형은 무엇입니까?

App ID 은 RSA-SHA256 알고리즘을 사용하여 XML 디지털 서명을 처리합니다.

App ID와 작동하도록 SAML ID 제공자 구성

App ID 의 메타데이터를 ID 공급업체에 제공하고 ID 공급업체의 메타데이터를 App ID 에 제공하여 App ID 과 연동하도록 SAML ID 공급업체를 구성할 수 있습니다.

ID 제공자에 메타데이터 제공

앱을 구성하려면 SAML 호환 가능 ID 제공자에 정보를 제공해야 합니다. 정보는 신뢰 구축에 사용되는 구성 데이터도 포함된 메타데이터 XML 파일을 통해 교환됩니다.

ID 제공자로 SAML을 구성한 후에는 SAML을 사용으로 설정할 수 없습니다.

  1. App ID 대시보드의 관리 탭에서 SAML 행의 편집을 클릭하여 설정을 구성하십시오.

  2. SAML 메타데이터 파일 다운로드를 클릭하십시오. ID 제공자는 파일에서 다음 정보를 예상합니다.

    메타데이터 파일에 있는 정보
    가변 설명
    EntityID App ID이(가) SAML 요청을 발행했음을 ID 제공자에게알리는 ID입니다.
    Location URL 사용자 인증에 성공한 후에 ID 제공자가 SAML 어설션을 전송하는 위치입니다.
    Binding ID 제공자가 SAML 응답을 보내야 하는 방법에 대한 지시사항입니다.
    NameID Format ID 공급자가 어설션의 제목에 어떤 식별자 형식을 보내야 하는지, App ID 이 사용자를 식별하는 방법을 알 수 있습니다. ID가 사용해야 하는 양식은 &lt;saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"&gt;입니다.
    WantAssertionsSigned ID 제공자가 어설션에 서명해야 하는지 여부를 확인하는 방법입니다. 서비스는 어설션의 서명을 예상하지만 암호화된 어설션을 지원하지는 않습니다.
    KeyDescriptor 서명된 SAML 요청을 확인하고 응답을 암호화하도록 ID 제공자를 구성하는 데 사용할 수 있는 SAML 서명 및 암호화 인증서입니다.
  3. ID 제공자에 데이터를 제공하십시오. ID 제공자가 메타데이터 파일의 업로드를 지원하면 이를 수행할 수 있습니다. 그렇지 않으면 수동으로 특성을 구성하십시오. 모든 ID 제공자가 동일한 특성을 사용하지는 않으므로 모든 ID 제공자를 사용하지 않을 수도 있습니다.

    특성 이름은 ID 제공자 간에 서로 다를 수 있습니다.

  4. SAML 2.0 연합사용으로 전환하십시오.

App ID에 메타데이터 제공

ID 제공자로부터 데이터를 받아서 App ID에 제공할 수 있습니다. IBM Cloud 또는 ID 제공자에서 애플리케이션에 대한 로그인을 시작할 수 있습니다.

콘솔에서 메타데이터 제공

IBM Cloud UI에서 애플리케이션에 로그인하려면 다음 단계를 따르십시오.

  1. App ID 대시보드의 SAML 2.0 탭으로 이동하십시오.

  2. 제공자 이름을 추가하십시오. 기본 이름은 SAML입니다.

  3. SAML IdP의 메타데이터 제공 섹션에 다음과 같이 ID 제공자로부터 얻은 메타데이터를 입력하십시오.

    App ID 제공해야 하는 정보입니다
    가변 설명
    Sign-in URL 인증을 위해 사용자가 경로 재지정되는 URL입니다. 이는 SAML ID 제공자에 의해 호스팅됩니다.
    Entity ID SAML ID 제공자의 글로벌한 고유 이름입니다.
    Primary certificate SAML ID 제공자가 발행한 인증서입니다. 이는 SAML 어설션을 서명하고 유효성 검증하는 데 사용됩니다. 모든 제공자가 서로 다르지만, ID 제공자로부터 서명 인증서의 다운로드가 가능합니다. 인증서는 .pem 형식이어야 합니다.
  4. 선택사항: 기본 인증서에서 서명 유효성 검증이 실패하는 경우에 사용되는 보조 인증서를 제공하십시오. 서명 키가 동일하게 유지되면 App ID는 만료된 인증서에 대해 인증을 차단하지 않습니다.

  5. 저장 을 클릭하십시오.

인증 컨텍스트를 설정하시겠습니까? API를 통해 해당 작업을 수행할 수 있습니다.

콘솔에서 IdP-initiated 로그인 구성하기

선택 사항으로, ID 공급자의 UI에서 IBM Cloud 애플리케이션에 로그인하려는 경우, IdP-initiated 로그인을 사용하도록 설정할 수 있습니다.

콘솔에서 메타데이터 제공 섹션의 1~4단계를 따르세요. 그런 다음 다음 프로세스를 완료합니다.

  1. IdP 시작 로그인을 사용으로 설정하십시오.
  2. IdP 리디렉션 URL 입력하세요.
  3. 저장 을 클릭하십시오.

API로 메타데이터 제공

  1. /saml API 엔드포인트에 GET 요청을 보내 인증 컨텍스트 및 인증서를 포함한 현재 SAML 구성을 확인합니다.

    코드 예제:

    curl --request GET \
    https://us-south.appid.cloud.ibm.com/management/v4/<tenantID>/config/idps/saml \
    --header `Accept: application/json`
    

    출력 예:

    {
       "isActive": true,
       "config": {
       "entityID": "https://example.com/saml2/metadata/706634",
       "signInUrl": "https://example.com/saml2/sso-redirect/706634",
       "certificates": [
          "certificate-example-pem-format"
       ],
       "displayName": "my saml example",
       "authnContext": {
          "class": [
             "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
          ],
          "comparison": "exact"
       }
       }
    }
    
  2. 다음 예의 값을 제공자가 제공한 정보로 대체하여 SAML 구성을 작성하십시오. 예제에 표시된 값은 필수지만, 표에 표시된 추가 정보를 포함하도록 선택할 수 있습니다.

    "config": {
       "authnContext": {
       "class": [
          "urn:oasis:names:tc:SAML:2.0:ac:classes:YourChosenClassValue",
          "urn:oasis:names:tc:SAML:2.0:ac:classes:YourOtherChosenClassValue"
       ],
       "comparison": "sampleComparisonValue"}
       "entityID": "https://example.com/saml2/metadata/706634",
       "signInUrl": "https://example.com/saml2/sso-redirect/706634",
       "certificates": [
       "primary-certificate-example-pem-format"
       "secondary-certificate-example-pem-format"
       ],
       "displayName": "my saml example",
       "signRequest": true ,
       "encryptResponse": true
    }
    
    SAML 구성 변수
    가변 설명
    signInUrl 인증을 위해 사용자가 경로 재지정되는 URL입니다. 이는 SAML ID 제공자에 의해 호스팅됩니다.
    entityID SAML ID 제공자의 글로벌한 고유 이름입니다.
    displayName SAML 구성에 지정한 이름입니다.
    primary-certificate-example-pem-format SAML ID 제공자가 발행한 인증서입니다. 이는 SAML 어설션을 서명하고 유효성 검증하는 데 사용됩니다. 모든 제공자가 서로 다르지만, ID 제공자로부터 서명 인증서의 다운로드가 가능합니다. 인증서는 .pem 형식이어야 합니다.
    선택사항:secondary-certificate-example-pem-format SAML ID 제공자가 발행한 백업 인증서. 기본 인증서의 서명 유효성 검증이 실패할 경우에 사용됩니다. : 서명 키가 동일하게 유지되면 App ID는 만료된 인증서에 대한 인증을 차단하지 않습니다.
    선택사항:authnContext 인증 컨텍스트는 인증 및 SAML 어설션의 품질을 확인하는 데 사용됩니다. 코드에 클래스 배열 및 비교 문자열을 추가하여 인증 컨텍스트를 추가할 수 있습니다. classcomparison 매개변수를 둘 다 사용자의 고유한 값으로 업데이트해야 합니다. 예를 들어 class 매개변수는 urn:oasis:names:tc:SAML:2.0:ac:classes:YourChosenClassValue와 유사할 수 있습니다.
    선택사항:signRequest signRequest 플래그에서는 테넌트의 SAML 서명 개인 키를 사용하여 서명하는 ID 제공자에 서명된 SAML 요청을 보내는 기능을 제공합니다. 서명된 요청을 받도록 SAML ID 제공자를 구성하려면 KeyDescriptor use="signing" 필드에 다운로드할 수 있는 메타데이터 파일의 서명 인증서가 필요합니다. 기본적으로 요청 서명은 off로 설정됩니다.
    선택사항:encryptResponse encryptResponse 플래그를 사용하면 인증 요청의 일부로 ID 제공자로부터 암호화된 응답을 받을 수 있습니다. 암호화된 응답을 보내도록 SAML ID 제공자를 구성하려면 KeyDescriptor use="encryption" 필드에 있는 메타데이터 파일에서 찾을 수 있는 암호화 인증서가 필요합니다. 기본적으로 응답 암호화는 off로 설정됩니다.
  3. /saml API 엔드포인트에 PUT 요청을 보내 2단계에서 생성한 구성을 App ID 에 제공합니다. 사용자의 요청을 살펴보려면 다음 예를 확인하십시오.

    curl --request PUT \
    https://us-south.appid.cloud.ibm.com/management/v4/<tenantID>/config/idps/saml \
    --header `Accept: application/json` \
    --data \
    {
       "isActive": true,
       "config": {
       "entityID": "https://example.com/saml2/metadata/706634",
       "signInUrl": "https://example.com/saml2/sso-redirect/706634",
       "certificates": [
          "primary-certificate-example-pem-format"
       ],
       "displayName": "my saml example",
       }
    }
    

API로 IdP-initiated 로그인 구성하기

IdP-initiated 로그인을 구성하려면 다음 단계를 완료합니다.

  1. /saml API 엔드포인트에 GET 요청을 보내 인증 컨텍스트 및 인증서를 포함한 현재 SAML 구성을 확인합니다.

    코드 예제:

    curl --request GET \
    https://us-south.appid.cloud.ibm.com/management/v4/<tenantID>/config/idps/saml \
    --header `Accept: application/json`
    

    출력 예:

    {
       "isActive": true,
       "config": {
       "entityID": "https://example.com/saml2/metadata/706634",
       "signInUrl": "https://example.com/saml2/sso-redirect/706634",
       "certificates": [
          "certificate-example-pem-format"
       ],
       "displayName": "my saml example",
       "authnContext": {
          "class": [
             "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
          ],
          "comparison": "exact"
       }
       }
    }
    
  2. 다음 예의 값을 제공자가 제공한 정보로 대체하여 SAML 구성을 작성하십시오. 예제에 표시된 값은 필수지만, 표에 표시된 추가 정보를 포함하도록 선택할 수 있습니다.

    "config": {
       "authnContext": {
       "class": [
          "urn:oasis:names:tc:SAML:2.0:ac:classes:YourChosenClassValue",
          "urn:oasis:names:tc:SAML:2.0:ac:classes:YourOtherChosenClassValue"
       ],
       "comparison": "sampleComparisonValue"
       },
       "idpInitEnabled": true,
       "idpRedirectUrl": "https://example.com/redirect/endpoint",
       "entityID": "https://example.com/saml2/metadata/706634",
       "signInUrl": "https://example.com/saml2/sso-redirect/706634",
       "certificates": [
       "primary-certificate-example-pem-format"
       "secondary-certificate-example-pem-format"
       ],
       "displayName": "my saml example",
       "signRequest": true ,
       "encryptResponse": true
    }
    
    SAML 구성 변수
    가변 설명
    signInUrl 인증을 위해 사용자가 경로 재지정되는 URL입니다. 이는 SAML ID 제공자에 의해 호스팅됩니다.
    entityID SAML ID 제공자의 글로벌한 고유 이름입니다.
    displayName SAML 구성에 지정한 이름입니다.
    primary-certificate-example-pem-format SAML ID 제공자가 발행한 인증서입니다. 이는 SAML 어설션을 서명하고 유효성 검증하는 데 사용됩니다. 모든 제공자가 서로 다르지만, ID 제공자로부터 서명 인증서의 다운로드가 가능합니다. 인증서는 .pem 형식이어야 합니다.
    DefaultRelayState RelayState 의 초기값입니다. 이 변수는 ID 제공자의 설정에서 구성됩니다. 이 변수는 ID 공급자의 SAML 요청 시 idpRedirectUrl 대신 URL 리디렉션에 사용할 수 있습니다. 두 변수를 모두 설정하면 DefaultRelayState 의 값이 우선합니다. IdP-initiated 이 변수 중 하나를 설정하지 않으면 로그인에 실패합니다.
    idpInitEnabled IdP 시작 로그인을 사용으로 설정할지 여부를 표시하는 부울입니다.
    idpRedirectUrl 이 필드의 값은 null, 비어 있는 문자열 또는 유효한 http 또는 https 리디렉션 URL 일 수 있습니다. 참고: 이 필드 값이 null인 경우 DefaultRelayState 을 리디렉션으로 설정해야 합니다 URL. 두 변수를 모두 설정하면 DefaultRelayState 의 값이 우선합니다. IdP-initiated 이 변수 중 하나를 설정하지 않으면 로그인에 실패합니다.
    선택사항:secondary-certificate-example-pem-format SAML ID 제공자가 발행한 백업 인증서. 기본 인증서의 서명 유효성 검증이 실패할 경우에 사용됩니다. : 서명 키가 동일하게 유지되면 App ID는 만료된 인증서에 대한 인증을 차단하지 않습니다.
    선택사항:authnContext 인증 컨텍스트는 인증 및 SAML 어설션의 품질을 확인하는 데 사용됩니다. 코드에 클래스 배열 및 비교 문자열을 추가하여 인증 컨텍스트를 추가할 수 있습니다. classcomparison 매개변수를 둘 다 사용자의 고유한 값으로 업데이트해야 합니다. 예를 들어 class 매개변수는 urn:oasis:names:tc:SAML:2.0:ac:classes:YourChosenClassValue와 유사할 수 있습니다.
    선택사항:signRequest signRequest 플래그에서는 테넌트의 SAML 서명 개인 키를 사용하여 서명하는 ID 제공자에 서명된 SAML 요청을 보내는 기능을 제공합니다. 서명된 요청을 받도록 SAML ID 제공자를 구성하려면 KeyDescriptor use="signing" 필드에 다운로드할 수 있는 메타데이터 파일의 서명 인증서가 필요합니다. 기본적으로 요청 서명은 off로 설정됩니다.
    선택사항:encryptResponse encryptResponse 플래그를 사용하면 인증 요청의 일부로 ID 제공자로부터 암호화된 응답을 받을 수 있습니다. 암호화된 응답을 보내도록 SAML ID 제공자를 구성하려면 KeyDescriptor use="encryption" 필드에 있는 메타데이터 파일에서 찾을 수 있는 암호화 인증서가 필요합니다. 기본적으로 응답 암호화는 off로 설정됩니다.
  3. /saml API 엔드포인트에 PUT 요청을 보내 2단계에서 생성한 구성을 App ID 에 제공합니다. 사용자의 요청을 살펴보려면 다음 예를 확인하십시오.

    curl --request PUT \
    https://us-south.appid.cloud.ibm.com/management/v4/<tenantID>/config/idps/saml \
    --header `Accept: application/json` \
    --data \
       {
         "isActive": true,
         "config": {
             "entityID": "https://example.com/saml2/metadata/706634",
             "signInUrl": "https://example.com/saml2/sso-redirect/706634",
             "certificates": [
             "certificate-example-pem-format"
             ],
             "displayName": "my saml example",
             "authnContext": {
                 "class": [
                     "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
                 ],
             "comparison": "exact"
             },
             "idpInitEnabled": true,
             "idpRedirectUrl": "https://example.com/redirect/endpoint",
         }
    }
    

구성 테스트

SAML ID 제공자 및 App ID 간의 구성을 테스트할 수 있습니다.

  1. 구성을 저장했는지 확인하십시오.
  2. App ID 대시보드의 SAML 2.0 탭으로 이동하고 테스트를 클릭하십시오. 새 탭이 열립니다.
  3. ID 제공자가 이미 인증한 사용자로 로그인하십시오.
  4. 양식이 완료되면 다른 페이지로 경로 재지정됩니다.
    • 성공적 인증: App ID 및 ID 제공자 간의 연결이 정상적으로 작동 중입니다. 올바른 액세스 및 ID 토큰이 페이지에 표시됩니다.
    • 실패한 인증: 연결이 끊겼습니다. 오류 및 SAML 응답 XML 파일이 페이지에 표시됩니다.

SAML 프레임워크는 다중 프로파일, 플로우 및 구성을 지원하며, 이는 ID 제공자가 올바르게 구성되어야 함을 의미한다. 문제가 발생하면 인증 요청이 실패할 수 있는 몇 가지 일반적인 이유를 확인하거나 자세한 오류 코드는 SAML 사양을 참조하세요.