2.5. 인증 유형 구성


Ansible Automation Platform은 조직의 로그인 환경을 간소화하도록 구성할 수 있는 여러 인증 플러그인을 제공합니다. 다음은 제공되는 인증기 플러그인입니다.

2.5.1. OAuth 및 SSO 공급자의 콜백 URL 업데이트

Ansible Automation Platform 2.6의 아키텍처 변경 후 적절한 인증 흐름을 보장하기 위해 GitHub, Microsoft Entra ID, Keycloak, Generic OIDC, Google OAuth와 같은 ID 공급자(IdP)의 callback_url 을 업데이트합니다. 이번 업데이트에서는 callback_url 을 자동화 컨트롤러에서 플랫폼 게이트웨이로 리디렉션합니다. 이전에는 callback_url 이 고정된 값이지만 다음 절차에 설명된 대로 이제 동적으로 생성되며 각 인증자 인스턴스에 특정됩니다. 이러한 변경으로 인해 플랫폼 업그레이드 후에도 IdP 구성을 수동으로 업데이트해야 합니다.

중요

업그레이드 후에는 인증 방법이 비활성화됩니다. 플랫폼 관리자로서 인증자를 활성화할 수 있습니다.

일반적으로 callback_url 은 인증 방법이 구성되면 Ansible Automation Platform에서 자동으로 생성됩니다. Ansible Automation Platform 내에서 생성된 이 URL을 복사한 다음 IdP 설정에 붙여넣어야 합니다.

사전 요구 사항

  • 외부 IdP의 구성 설정에 대한 관리자 액세스 권한이 있습니다.

프로세스

  1. Ansible Automation Platform UI에서 인증자 구성 세부 정보로 이동하여 callback_url 을 찾습니다.

    자세한 내용은 인증자 세부 정보 표시를 참조하십시오.

  2. Ansible Automation Platform에서 특정 인증 방법에 제공하는 자동 생성 콜백 URL, 리디렉션 URL 또는 Reply URL 을 식별하고 복사합니다.
  3. Ansible Automation Platform의 복사된 리디렉션 URL을 필요한 경우 IdP 구성에 붙여넣어 IdP 설정을 업데이트합니다.

검증

callback_url 이 올바르게 업데이트되었으며 인증이 작동하는지 확인합니다.

  • Ansible Ansible Automation Platform에 관리자 계정으로 로그인하고 아직 없는 경우 인증 방법을 활성화합니다.
  • 새로 구성된 OAuth 또는 SSO 공급자를 사용하여 Ansible Automation Platform에 로그인합니다. 로그인에 성공하면 올바른 구성이 표시됩니다.

2.5.2. 인증자 시간 제한 구성

Ansible Automation Platform은 LDAP, RADIUS, TACACS+와 같은 암호 기반 인증기에 계층화된 시간 초과 시스템을 사용합니다. 인증 요청이 실패하지 않도록 하려면 다른 요청과 관련하여 각 시간 초과 설정을 구성합니다. 원칙은 각 업스트림 시간 초과가 다운스트림 시간 초과의 합계보다 약간 길어야 한다는 것입니다.

시스템은 각각 자체 시간 초과 설정을 사용하여 일련의 서비스를 통해 인증 요청을 처리합니다.

  • Envoy timeout: 요청이 초기 진입점(Envoy)이 연결을 종료하기 전에 취할 수 있는 총 시간입니다. 이는 가장 높은 수준의 시간 초과입니다.
  • gRPC 시간 초과: 내부 인증 서비스와 통신하는 데 소요되는 시간을 제한하는 다운스트림 타임아웃입니다.
  • Authenticator 시간 초과: 개별 인증자(LDAP, RADIUS, TACACS+)가 타사 서버의 응답을 기다리는 시간을 정의하는 가장 낮은 수준의 시간 초과입니다.

2.5.2.1. 시간 초과 값 설정

인증 서버의 성능 요구 사항에 따라 제한 시간 값을 구성하는 것이 좋습니다. 설치 프로그램은 Ansible Automation Platform 구성 요소에 대한 시간 초과를 설정하는 방법을 제공하지만 시스템 관리자는 여전히 개별 인증자 시간 초과를 검토하고 조정하여 특정 환경에 맞게 조정해야 합니다.

프로세스

  • 인증자 시간 초과 구성: 각 인증기의 시간 초과 설정을 외부 서버의 예상 응답 시간과 일치하는 값으로 조정합니다.

    • LDAP의 경우 OPT_NETWORK_TIMEOUT 을 초 단위로 설정합니다. 예를 들어 OPT_NETWORK_TIMEOUT: 30은 LDAP 시간 초과를 30초로 설정합니다. 자세한 내용은 LDAP 인증 구성을 참조하십시오.
    • TACACS+ 인증의 경우 시간 초과를 변경하려면 플랫폼 게이트웨이 API를 통해 수행해야 합니다.
    • RADIUS 인증의 경우 시간 초과는 변경할 수 없으며 5초로 설정됩니다.

2.5.3. 로컬 인증 구성

플랫폼 관리자는 로컬 시스템 인증을 구성할 수 있습니다. 로컬 인증을 사용하면 사용자와 암호가 로컬 시스템 계정에 대해 확인됩니다.

참고

로컬 인증자는 Ansible Automation Platform 설치 프로세스에서 자동으로 생성되며 설치 전에 인벤토리 파일에서 지정된 관리자 인증 정보로 구성됩니다. 설치가 완료되면 해당 인증 정보를 사용하여 Ansible Automation Platform에 로그인할 수 있습니다.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 로컬 구성 의 이름을 입력합니다. 구성 이름은 필수이며 모든 인증자 간에 고유해야 하며 512자를 초과해서는 안 됩니다.
  4. 인증 유형 목록에서 Local 을 선택합니다.
  5. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  6. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  7. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  8. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  9. Next를 클릭합니다.

2.5.4. LDAP 인증 구성

플랫폼 관리자는 Ansible Automation Platform 사용자의 계정 인증 정보 소스로 LDAP를 구성할 수 있습니다.

참고

연결하려는 LDAP 서버에 자체 서명되거나 내부 CA(인증 기관)에서 서명한 인증서가 있는 경우 CA 인증서를 시스템의 신뢰할 수 있는 CA에 추가해야 합니다. 그러지 않고 LDAP 서버에 연결하면 인증서 발행자를 인식할 수 없다는 오류가 발생합니다.

기본 Red Hat Enterprise Linux 신뢰 저장소를 사용하는 경우 LDAP 인증서가 자동으로 마이그레이션되지 않습니다. Ansible Automation Platform을 업그레이드하고 LDAP 인증이 시스템의 신뢰 저장소에 추가된 인증서에 의존하는 경우 Ansible Automation Platform 2.6의 플랫폼 게이트웨이로 이 LDAP 인증서 구성이 자동으로 마이그레이션되지 않습니다.

  • Ansible Automation Platform 2.4에서 Ansible Automation Platform 2.6으로의 업그레이드의 경우:

    • 자동화 컨트롤러에서 플랫폼 게이트웨이로의 모든 인증 구성의 마이그레이션이 자동화됩니다. 여기에는 자동화 컨트롤러에서 플랫폼 게이트웨이로 SAML 개인 키 또는 OAuth 시크릿 키와 같은 타사 인증 구성 및 민감한 구성 데이터가 포함됩니다. 그러나 사용자 지정 LDAP 인증서를 사용하는 경우 해당 인증서에 대해 다음 절차를 완료해야 합니다.
    • LDAP AUTH_LDAP_USER_FLAGS_BY_GROUP 설정의 is_superuseris_system_auditor 플래그가 새 플랫폼 게이트웨이로 성공적으로 마이그레이션됩니다. 그러나 is_active 플래그는 플랫폼 게이트웨이에서 사용할 수 없으므로 마이그레이션되지 않습니다. 대신 거부 규칙을 사용하여 사용자가 시스템에 대한 액세스를 방지할 수 있습니다.
  • Ansible Automation Platform 2.5에서 Ansible Automation Platform 2.6으로의 업그레이드의 경우 인증기 구성은 자동화 컨트롤러에서 자동으로 마이그레이션되지 않습니다. Ansible Automation Platform 2.5에서 인증을 구성한 경우 2.6으로 업그레이드한 후 해당 설정은 현재 구성된 대로 유지됩니다. LDAP의 경우 2.5에서 사용자 정의 인증서를 사용한 경우 이 인증서도 마이그레이션해야 합니다.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 LDAP 를 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. LDAP Server URI 필드에 연결하려는 LDAP 서버 목록을 입력하거나 수정합니다. 이 필드는 여러 주소를 지원합니다.
  6. LDAP 바인딩 DN 텍스트 필드에 Distinguished Name (DN)을 입력하여 다음 예와 같이 Ansible Automation Platform에서 LDAP 서버에 연결하는 데 사용하는 사용자를 지정합니다.

    cn=josie,cn=users,dc=website,dc=com
  7. LDAP 바인딩 암호 텍스트 필드에 바인딩 사용자에게 사용할 암호를 입력합니다.
  8. LDAP 그룹 유형 목록에서 그룹 유형을 선택합니다.

    그룹 유형은 LDAP 디렉터리의 사용자와 연결된 그룹을 관리하고 이 절차의 14단계에서 지정된 검색에 의해 반환되는 그룹의 클래스 이름을 정의합니다. 그룹 유형(그룹 매개 변수 및 그룹 검색)은 로그인 중에 사용자를 찾아 할당하는 데 사용되며 매핑 프로세스 중에도 평가할 수 있습니다. 다음 표에는 사용 가능한 그룹 유형 및 각각에 필요한 매개변수가 나열되어 있습니다. 기본적으로 LDAP 그룹은 cn 속성의 첫 번째 값을 사용하여 Django 그룹에 매핑됩니다. name_attr 을 사용하여 다른 속성을 지정할 수 있습니다. 예를 들면 name_attr='cn' 입니다.

    Expand
    표 2.1. 사용 가능한 LDAP 그룹 유형
    LDAP 그룹 유형description이니셜라이저 메서드(init)

    PosixGroupType

    posixGroup 개체 클래스를 처리합니다. 이 명령은 기본 그룹 및 그룹 멤버십을 모두 확인합니다.

    name_attr='cn'

    MemberDNGroupType

    그룹 오브젝트에 해당 멤버 DN 목록이 포함된 그룹화 메커니즘을 처리합니다.

    member_attr, name_attr='cn'

    GroupOfNamesType

    groupOfNames 오브젝트 클래스를 처리합니다. MemberDNGroupType('member') 과 동일합니다.

    name_attr='cn'

    GroupOfUniqueNamesType

    groupOfUniqueNames 오브젝트 클래스를 처리합니다. MemberDNGroupType('uniqueMember') 과 동일합니다.

    name_attr='cn'

    ActiveDirectoryGroupType

    Active Directory 그룹을 처리합니다. MemberDNGroupType('member') 과 동일합니다.

    name_attr='cn'

    OrganizationalRoleGroupType

    organizationalRole 개체 클래스를 처리합니다. MemberDNGroupType('roleOccupant') 과 동일합니다.

    name_attr='cn'

    NestedGroupOfNamesType

    groupOfNames 오브젝트 클래스를 처리합니다. NestedMemberDNGroupType('member') 과 동일합니다.

    member_attr, name_attr='cn'

    NestedGroupOfUniqueNamesType

    groupOfUniqueNames 오브젝트 클래스를 처리합니다. NestedMemberDNGroupType('uniqueMember') 과 동일합니다.

    name_attr='cn'

    NestedActiveDirectoryGroupType

    Active Directory 그룹을 처리합니다. NestedMemberDNGroupType('member') 과 동일합니다.

    name_attr='cn'

    NestedOrganizationalRoleGroupType

    organizationalRole 개체 클래스를 처리합니다. NestedMemberDNGroupType('roleOccupant') 과 동일합니다.

    name_attr='cn'

    참고

    Ansible Automation Platform에서 지원하는 그룹 유형은 기본 django-auth-ldap 라이브러리 를 사용합니다. 선택한 그룹 유형에 대한 매개변수를 지정하려면 이 절차의 14단계를 참조하십시오.

  9. LDAP 사용자 DN 템플릿을 사용자 검색 대신 사용할 수 있습니다. 이 방법은 조직 환경에서 사용할 수 있는지 검색하는 것보다 사용자 조회에 더 효율적입니다. 다음 예에 표시된 대로 템플릿 이름을 입력합니다.

    uid=%(user)s,cn=users,cn=accounts,dc=example,dc=com

    여기서 uid 는 사용자 식별자이며 cn 은 공통 이름이며 dc 는 도메인 구성 요소입니다.

    참고

    이 설정의 값이 있으면 LDAP 사용자 검색 설정 대신 사용됩니다.

  10. LDAP 시작 TLS 는 기본적으로 비활성화되어 있습니다. StartTLS를 사용하면 LDAP 연결을 암호화되지 않은 연결에서 TLS(Transport Layer Security)를 사용하여 보안 연결로 업그레이드할 수 있습니다. LDAP 연결이 SSL을 사용하지 않는 경우 StartTLS를 활성화하려면 스위치를 On 으로 설정합니다.
  11. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  12. LDAP 연결에 설정할 LDAP 연결 옵션을 입력합니다. 기본적으로 LDAP 추천은 특정 LDAP 쿼리가 Active Directory로 중단되지 않도록 비활성화되어 있습니다. 옵션 이름은 다음 예와 같이 문자열이어야 합니다.

    OPT_REFERRALS: 0
    OPT_NETWORK_TIMEOUT: 30

    설정할 수 있는 가능한 옵션 및 값은 python-LDAP 참조를 참조하십시오.

  13. 선택한 LDAP 그룹 유형에 따라 LDAP 그룹 유형 매개 변수 필드에서 다른 매개변수를 사용할 수 있습니다. LDAP_GROUP_TYPE_PARAMSkwargs 로 변환되어 선택한 LDAP 그룹 유형 클래스에 전달되는 사전입니다. 그룹 유형에서 사용하는 일반적인 매개 변수는 name_attrmember_attr 입니다. 여기서 name_attr 의 기본값은 cn 이고 member_attr 의 기본값은 member 입니다.

    {"name_attr": "cn", "member_attr": "member"}

    특정 LDAP 그룹 유형에 필요한 매개변수를 확인하려면 클래스 init 매개변수에 대한 django_auth_ldap 설명서 를 참조하십시오.

  14. LDAP 그룹 검색 필드에서 다음 예와 같이 검색할 그룹과 검색 방법을 지정합니다.

    [
    "dc=example,dc=com",
    "SCOPE_SUBTREE",
    "(objectClass=group)"
     ]
  15. LDAP 사용자 속성 맵 필드에 LDAP 필드를 Ansible Automation Platform 사용자에게 매핑하는 사용자 속성을 입력합니다(예: 다음 예와 같이 email 또는 first_name ).

    {
    "first_name": "givenname",
    "last_name": "sn",
    "email": "mail"
    }
  16. LDAP 사용자 검색 필드에 다음 예와 같이 인증 중에 사용자를 검색할 위치를 입력합니다.

    [
    "ou=users,dc=website,dc=com",
    "SCOPE_SUBTREE",
    "(cn=%(user)s)"
    ]

    LDAP 사용자 DN 템플릿이 설정되지 않은 경우 Ansible Automation Platform은 DN 템플릿 바인딩 및 LDAP 바인딩 암호를 사용하여 LDAP에 인증합니다. 인증 후 LDAP 검색을 수행하여 이 필드에서 지정한 사용자를 찾습니다. 사용자가 있는 경우 Ansible Automation Platform은 LDAP 검색에서 찾은 사용자에 대해 제공된 암호를 검증합니다. 다음 예와 같이 여러 검색 용어를 입력하여 LDAPUnion 이 있는 사용자가 여러 검색 쿼리를 지원합니다.

    [
        [
            "ou=users,dc=example,dc=com",
            "SCOPE_SUBTREE",
            "uid=%(user)s"
        ],
         [
            "ou=employees,dc=subdivision,dc=com",
            "SCOPE_SUBTREE",
            "uid=%(user)s"
         ]
    ]

    여러 검색 중에 고유하지 않은 사용자를 찾으면 해당 사용자는 Ansible Automation Platform에 로그인할 수 없습니다. 제공된 예제에 따라 uid=jdoeou=users,dc=example,dc=comou=employees,dc=subdivision,dc=com 에 로그인할 수 없는 사용자가 있는 경우입니다. 두 분기에 있는 다른 모든 고유한 사용자는 계속 로그인할 수 있습니다.

    참고

    LDAP 사용자 DN 템플릿 필드가 채워지면 LDAP 사용자 검색 필드보다 우선하며 템플릿만 사용자를 인증하는 데 사용됩니다.

  17. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  18. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  19. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  20. 인증 메서드 생성을 클릭합니다.

2.5.4.1. LDAPS 통합을 위한 자동화 컨트롤러에서 인증 기관 가져오기

LDAP를 사용하여 자동화 컨트롤러 서버에 인증할 수 있습니다. 그러나 LDAPS(LDAP over SSL/TLS)를 사용하여 인증하고 플랫폼 게이트웨이에서 TLS 인증서를 신뢰하지 않으면 다음과 같은 오류와 함께 실패합니다.

2025-08-26 16:40:56,141 WARNING   django_auth_ldap Caught LDAPError while authenticating: SERVER_DOWN({'result': -1, 'desc': "Can't contact LDAP server", 'ctrls': [], 'info': 'error:0A000086:SSL routines::certificate verify failed (self-signed certificate)'})

Ansible Automation Platform이 LDAP에서 제공하는 인증서를 신뢰하도록 하려면 모든 플랫폼 게이트웨이 인스턴스에서 다음 절차를 수행합니다.

프로세스

  1. 디렉터리에 LDAP 서버 인증서의 사본을 배치합니다. /etc/pki/ca-trust/source/anchors/.
  2. 명령을 실행합니다.

    update-ca-trust

2.5.5. SAML 인증 구성

SAML을 사용하면 IdM(Identity Provider)과 서비스 공급자(SP) 간에 인증 및 권한 부여 데이터를 교환할 수 있습니다. Ansible Automation Platform은 사용자를 인증하기 위해 하나 이상의 SAML IdP와 통신하도록 구성할 수 있는 SAML SP입니다.

SAML IdP에서 선택적으로 제공하는 그룹 및 속성에 따라 사용자는 이 인증자와 연결된 인증자 맵을 기반으로 Ansible Automation Platform의 팀과 조직에 배치할 수 있습니다. 이 매핑을 사용하면 사용자가 SAML을 통해 로그인할 때 Ansible Automation Platform에서 사용자를 올바르게 식별하고 지정된 이름, 성, 이메일 및 그룹 멤버십과 같은 적절한 속성을 할당할 수 있습니다.

사전 요구 사항

Ansible Automation Platform에서 SAML 인증을 구성하기 전에 다음을 수행해야 합니다.

  • SAML IdM(Identity Provider)을 구성합니다.
  • Ansible Automation Platform과의 통합에 필요한 설정을 사용하여 SAML IdP를 미리 구성합니다. 예를 들어 Microsoft Entra ID에서 다음을 구성할 수 있습니다.

    • ID(암호 ID): 원하는 모든 값일 수 있지만 Ansible Automation Platform에 구성된 값과 일치해야 합니다.
    • 응답 URL(ACS) URL: SAML 방법이 Ansible Automation Platform에 구성되면 이 URL이 자동으로 생성됩니다. Ansible Automation Platform에서 해당 값을 복사하여 IdP 설정에 붙여넣습니다.
  • SAML IdP 애플리케이션의 사용자 속성을 수집합니다. IdP마다 다른 속성 이름과 형식을 사용할 수 있습니다. 정확한 특성 이름과 예상되는 값은 특정 IdP에 대한 설명서를 참조하십시오.
  • 다음 명령을 사용하여 개인 키 및 공용 인증서를 생성합니다.

    $ openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 SAML 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 SAML 을 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. SAML 서비스 공급자 엔터티 ID 필드에서 SAML 서비스 공급자 구성의 대상으로 사용되는 애플리케이션 정의 고유 식별자를 입력합니다. 일반적으로 서비스 공급자의 기본 URL이지만 실제 값은 IdP에서 예상되는 엔터티 ID에 따라 다릅니다.
  6. SAML 서비스 공급자 공용 인증서 필드에 인증서 콘텐츠를 포함합니다. 이 정보는 사전 요구 사항으로 생성한 cert.pem에 포함되어 있으며 --BEGIN CERTIFICATE- 및 --END CERTIFICATE -- 를 포함해야 합니다.
  7. SAML 서비스 공급자 개인 키 필드에 개인 키 콘텐츠를 포함합니다. 이 정보는 사전 요구 사항으로 생성한 key.pem에 포함되어 있으며 --BEGIN PRIVATE KEY----END PRIVATE KEY ---을 포함해야 합니다.
  8. IdP 로그인 URL 필드에서 로그인 시작을 위해 사용자를 리디렉션할 URL 을 입력합니다. SAML IdP 애플리케이션의 로그인 URL입니다.
  9. IdP Public Cert 필드에 IdP에서 제공하는 보안에 사용되는 공개 인증서를 입력합니다. IdP에서 다운로드할 수 있는 SAML 인증서입니다.

    참고

    IdP Public Cert 필드의 IdP에는 --BEGIN- 및 --END CERTIFICATE-- 를 포함한 전체 인증서가 포함되어야 합니다. IdP를 포함하지 않는 경우 접두사 및 접미사를 수동으로 입력해야 합니다.

  10. 엔터티 ID의 어설션에 반환된 엔터티 ID 를 입력합니다. IdP SAML 애플리케이션의 식별자입니다. IdP에서 제공하는 SAML 메타데이터에서 이 값을 찾을 수 있습니다.
  11. 그룹, 사용자 이메일 , 사용자 이름 , 사용자 성사용자 이름사용자 세부 정보를 입력합니다.
  12. User Permanent ID 필드에 사용자의 영구 ID를 입력합니다. 이 필드는 필수입니다.

    참고

    SAML IdP를 통해 추가 속성을 사용할 수 있습니다. 이러한 값은 additional Authenticators 필드 또는 extra_data 속성 매핑 필드에 SAML IDP에 포함되어야 합니다. 자세한 내용은 해당 단계를 참조하십시오.

  13. SAML Assertion Consumer Service (ACS) URL 필드는 구성한 각 ID 공급자(IdP)가 있는 서비스 공급자(SP)로 서비스를 등록합니다. 이 필드를 비워 둡니다. 이 인증 방법을 저장하면 자동으로 생성됩니다. 이 필드는 IdP의 Reply URL 설정과 일치해야 합니다.
  14. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다. 예를 들어, Email, Username, Last Name, First Name이 아닌 모든 SAML IdP 속성을 매핑하려면 다음을 입력합니다.

    GET_ALL_EXTRA_DATA: true

    또는 SAML IDP에 대한 extra_data 속성 매핑 필드에 SAML IdP 속성 목록을 포함할 수 있습니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  15. SAML 서비스 공급자 조직 정보 필드에 URL, 표시 이름 및 앱 이름을 제공합니다.

    {
      "en-US": {
        "url": "http://www.example.com",
        "displayname": "Example",
        "name": "example"
      }
    }
  16. SAML 서비스 공급자 기술 연락처 필드에서 서비스 공급자에 대한 기술 담당자의 이름 및 이메일 주소를 지정합니다.

    {
    "givenName": "Some User",
    "emailAddress": "suser@example.com"
    }
  17. SAML 서비스 공급자 지원 연락처 필드에서 서비스 공급자에 대한 지원 담당자의 이름 및 이메일 주소를 지정합니다.

    {
    "givenName": "Some User",
    "emailAddress": "suser@example.com"
    }
  18. 선택 사항: SAML 서비스 공급자 추가 구성 데이터 필드에서 추가 구성 데이터를 제공합니다. 예를 들어 추가 보안을 위해 서명 요청을 사용하도록 선택할 수 있습니다.

    {
    "sign_request": True,
    }

    이 필드는 API의 SOCIAL_AUTH_SAML_SP_EXTRA 와 동일합니다. 자세한 내용은 OneLogin' SAML Python Toolkit 에서 유효한 서비스 공급자 추가(SP_EXTRA) 매개변수에 대해 알아보십시오.

  19. 선택 사항: SAML 보안 구성 필드에서 보안 설정을 제공합니다. 이 필드는 API의 SOCIAL_AUTH_SAML_SECURITY_CONFIG 필드와 동일합니다.

    // Indicates whether the <samlp:AuthnRequest> messages sent by this SP // will be signed. [Metadata of the SP will offer this info]
    "authnRequestsSigned": false,
    
    // Indicates a requirement for the <samlp:Response>, <samlp:LogoutRequest> // and <samlp:LogoutResponse> elements received by this SP to be signed.
    "wantMessagesSigned": false,
    
    // Indicates a requirement for the <saml:Assertion> elements received by // this SP to be signed. [Metadata of the SP will offer this info]
    "wantAssertionsSigned": false,
    
    // Authentication context.
    // Set to false and no AuthContext will be sent in the AuthNRequest,
    // Set true or don't present this parameter and you will get an AuthContext 'exact' 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport'
    // Set an array with the possible auth context values: array ('urn:oasis:names:tc:SAML:2.0:ac:classes:Password', 'urn:oasis:names:tc:SAML:2.0:ac:classes:X509'),
    "requestedAuthnContext": true,

    자세한 내용 및 추가 옵션은 OneLogin의 SAML Python Toolkit 을 참조하십시오.

  20. 선택 사항: SAML IDP에서 extra_data 속성 매핑 필드에 IDP 속성을 extra_data 속성에 매핑하는 값을 입력합니다. 이러한 값에는 매핑할 이메일 또는 Username과 같은 표준 속성 이외의 추가 사용자 정보가 포함됩니다. 예를 들면 다음과 같습니다.

    - Department
    - UserType
    - Organization

    포함할 수 있는 값에 대한 자세한 내용은 고급 SAML 설정을 참조하십시오.

    중요

    구성에 모든 항목이 올바르게 매핑되도록 모든 관련 값을 포함해야 합니다. 또는 추가 Authenticator 필드에 GET_ALL_EXTRA_DATA: true 를 추가하여 사용 가능한 모든 SAML IdP 특성을 매핑할 수 있습니다.

  21. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  22. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  23. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  24. 인증 메서드 생성을 클릭합니다.

    중요

    Operator 기반 배포에서 SAML에 대한 HTTPS 리디렉션을 구성하여 사용자의 로그인을 간소화할 수 있습니다. 이 설정을 구성하는 단계는 OpenShift Container Platform의 플랫폼 게이트웨이에 대한 SSO(Single Sign-On) 활성화를 참조하십시오.

2.5.5.1. 투명한 SAML 로그인 구성

투명한 로그인이 작동하려면 먼저 IdP 시작 로그인이 실행되어야 합니다.

프로세스

  • IdP의 RelayState 를 "IdP"로 설정합니다.

2.5.6. TACACS+ 인증 구성

TACACS+(Terminal Access Controller Access-Control System Plus)는 중앙 집중식 서버를 통한 네트워크 액세스 제어를 위해 원격 인증 및 관련 서비스를 처리하는 프로토콜입니다. TACACS+는 인증, 권한 부여 및 회계(AAA) 서비스를 제공합니다. 이 서비스는 인증 소스로 사용할 Ansible Automation Platform을 구성할 수 있습니다.

참고

이 기능은 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 TACACS+ 를 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. 다음 정보를 입력합니다.

    • TACACS+ 서버의 호스트 이름: 인증할 TACACS+ 서버의 호스트 이름 또는 IP 주소를 제공합니다. 이 필드를 비워 두면 TACACS+ 인증이 비활성화됩니다.
    • TACACS+ 인증 프로토콜: TACACS+ 클라이언트에서 사용하는 프로토콜입니다. 옵션은 ascii 또는 pap입니다.
    • TACACS+ 서버에 인증을 위한 공유 시크릿: TACACS+ 인증 서버의 시크릿 키입니다.
  6. TACACS+ 클라이언트 주소 전송 활성화 는 기본적으로 비활성화되어 있습니다. 클라이언트 주소 전송을 활성화하려면 확인란을 선택합니다.
  7. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  8. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  9. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  10. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  11. 인증 메서드 생성을 클릭합니다.

2.5.7. Microsoft Entra ID 인증 구성

이전에 Microsoft Azure AD(Active Directory)로 알려진 Microsoft Entra ID에 대한 엔터프라이즈 인증을 설정하려면 다음 단계를 따르십시오.

  1. 이 절차의 단계를 사용하여 Microsoft Entra ID 인증을 사용하도록 Ansible Automation Platform을 구성합니다.
  2. 빠른 시작: Microsoft ID 플랫폼에 애플리케이션을 등록하여 Microsoft Entra ID에 Ansible Automation Platform 등록합니다. 이 프로세스에서는 애플리케이션(클라이언트) ID 및 애플리케이션 시크릿을 제공합니다.
  3. Microsoft Entra ID에 리디렉션 URL을 추가합니다. 플랫폼에서 Microsoft Entra ID 인증에 대한 구성 마법사를 완료한 후 Azure AD OAuth2 콜백 URL 필드에 표시된 URL 을 복사합니다. 그런 다음 Azure에서 등록된 엔터프라이즈 애플리케이션으로 이동하여 애플리케이션에 리디렉션 URI를 추가하는 방법에 설명된 대로 리디렉션 URL (Ansible Automation Platform에서 콜백 URL 이라고도 함)으로 이 URL을 추가합니다. 이 단계는 로그인 흐름이 올바르게 작동하려면 필요합니다.

Microsoft Entra ID에서 제공하는 속성은 이 인증 유형에 대한 Ansible Automation Platform 구성에 설정되지 않습니다. 대신 social_core azuread 백엔드 는 Microsoft Entra ID에서 제공하는 클레임의 변환을 제공합니다. Ansible Automation Platform에서 사용자를 올바르게 식별하고 지정된 이름, 성, 이메일 및 사용자 이름과 같은 적절한 속성을 할당할 수 있는 사용자 속성은 다음과 같습니다.

Expand
Ansible Automation Platform 속성Microsoft Entra ID 매개변수

authenticator_uid

UPN

사용자 이름

name

이름

given_name

family_name

이메일

이메일 (위쪽으로 돌아가기)

각 키와 시크릿은 고유한 애플리케이션에 속해야 하며 여러 인증 백엔드 간에 공유하거나 재사용할 수 없습니다. 애플리케이션을 등록하려면 인증자 구성에 표시된 콜백 URL인 웹 페이지 URL을 제공해야 합니다. 이 정보에 액세스하는 방법에 대한 지침은 인증자 세부 정보 표시를 참조하십시오.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 Azuread 를 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. 편집을 클릭하고 Microsoft의 애플리케이션(Client) ID 를 복사하여 OIDC 키 필드에 붙여넣습니다.
  6. Microsoft Entra ID가 그룹 클레임에 사용자 그룹 정보를 제공하도록 구성된 경우 플랫폼이 Microsoft Entra ID 구성과 일치하는 그룹 클레임 이름으로 구성되어 있는지 확인합니다. 이를 통해 플랫폼은 Microsoft Entra ID를 통해 로그인하는 사용자의 그룹을 올바르게 식별하고 연결할 수 있습니다.

    참고

    Microsoft Entra ID에서 제공되는 그룹은 고유한 ID 또는 그룹 이름을 사용하여 식별할 수 있습니다. Microsoft Entra ID Authenticator에 대한 그룹 매핑을 생성할 때 고유한 ID 또는 그룹 이름을 사용할 수 있습니다.

    기본적으로 Microsoft Entra ID는 그룹을 기본 그룹 클레임 이름으로 사용합니다. 따라서 값을 기본값으로 설정하거나 IdP에 설정한 사용자 정의 재정의를 설정해야 합니다. 명시적으로 변경되지 않는 한 현재 기본값은 기존 동작을 보존하도록 설정됩니다.

  7. Microsoft ID 플랫폼에 애플리케이션을 등록하기 위한 지침에 따라 인증을 위해 키(한 번만 표시)를 클라이언트에 제공합니다.
  8. Microsoft Entra ID/Microsoft Azure AD 애플리케이션에 대해 생성된 시크릿 키를 OIDC 시크릿 필드에 복사하여 붙여넣습니다.
  9. 선택 사항: 기본적으로 Microsoft Entra ID의 name 속성은 Ansible Automation Platform 내에서 사용자 이름 필드로 사용됩니다. 해당 기본값을 재정의하고 Microsoft Entra ID의 다른 속성을 사용하려면 사용자 이름 필드에 해당 속성을 입력합니다.
  10. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  11. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  12. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  13. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  14. 인증 메서드 생성을 클릭합니다.

검증

인증이 올바르게 구성되었는지 확인하려면 Ansible Automation Platform에서 로그아웃하고 로그인 화면에 해당 자격 증명으로 로그인할 수 있는 인증 선택한 방법의 로고가 표시되는지 확인합니다.

다음 단계

Ansible Automation Platform 서버에 허용되는 사용자를 제어하고 특성(예: 사용자 이름 및 이메일 주소) 또는 해당 그룹(예: 사용자 이름 및 이메일 주소)을 기반으로 Ansible Automation Platform 조직 또는 팀에 배치하려면 해당 그룹에 속하는 그룹을 계속 매핑 합니다.

2.5.8. Google OAuth2 인증 구성

Google에 대한 소셜 인증을 설정하려면 웹 애플리케이션의 OAuth2 키와 시크릿을 가져와야 합니다. 이 작업을 위해 먼저 프로젝트를 생성하고 Google로 설정해야 합니다.

자세한 내용은 Google API 콘솔 도움말 설명서에서 OAuth 2.0 설정을 참조하십시오.

설정 프로세스를 이미 완료한 경우 Google API Manager 콘솔 의 인증 정보 섹션으로 이동하여 해당 인증 정보에 액세스할 수 있습니다. OAuth2 키(Client ID) 및 시크릿(Client secret)은 UI에 필요한 필드를 제공하는 데 사용됩니다.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 Google OAuth 를 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. Google OAuth2 키Google OAuth2 시크릿 필드는 미리 채워져 있습니다.

    그렇지 않은 경우 웹 애플리케이션 설정 프로세스 중에 Google에서 제공한 인증 정보를 사용합니다. 다음 단계에서 사용할 수 있도록 이러한 설정을 저장합니다.

  6. Google 클라이언트 ID를 복사하여 Google OAuth2 키 필드에 붙여넣습니다.
  7. Google 클라이언트 시크릿을 복사하여 Google OAuth2 시크릿 필드에 붙여넣습니다.
  8. 선택 사항: 지침 및 필수 형식에 제공된 툴팁을 사용하여 다음 필드에 대한 정보를 입력합니다.

    • 액세스 토큰 URL
    • 액세스 토큰 방법
    • 권한 부여 URL
    • 토큰 취소 방법
    • 토큰 URL 취소
    • OIDC JWT Algorithm(s)
    • OIDC JWT
  9. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  10. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  11. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  12. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  13. 인증 메서드 생성을 클릭합니다.

검증

인증이 올바르게 구성되었는지 확인하려면 Ansible Automation Platform에서 로그아웃하고 로그인 화면에 해당 자격 증명으로 로그인할 수 있는 인증 선택한 방법의 로고가 표시되는지 확인합니다.

2.5.9. 일반 OIDC 인증 구성

OpenID Connect(OIDC)는 OAuth 2.0 프레임워크를 사용합니다. 이를 통해 타사 애플리케이션에서 ID를 확인하고 기본 최종 사용자 정보를 얻을 수 있습니다. OIDC와 SAML의 주요 차이점은 SAML에 서비스 공급자(SP)-to-IdP 신뢰 관계가 있는 반면 OIDC는 보안 토큰을 얻는 데 사용되는 채널(HTTPS)을 사용하여 신뢰를 설정합니다. Ansible Automation Platform을 사용하여 OIDC를 설정하는 데 필요한 인증 정보를 얻으려면 OIDC가 지원되는 선택한 IdP의 설명서를 참조하십시오.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 일반 OIDC 를 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. 다음 정보를 입력합니다.

    • OIDC 공급자 URL: OIDC 공급자의 URL입니다.
    • OIDC 키: 타사 IdP의 클라이언트 ID입니다.
    • OIDC Secret: IdP의 클라이언트 시크릿입니다.
  6. 선택 사항: Access Token Method 목록에서 액세스 토큰을 요청할 때 사용할 HTTP 방법을 선택합니다. 기본 메서드는 POST 입니다.
  7. 필요한 경우 지침 및 필수 형식에 제공된 툴팁을 사용하여 다음 필드에 대한 정보를 입력합니다.

    • Access Token Method - 기본 메서드는 POST 입니다.
    • 액세스 토큰 URL
    • 액세스 토큰 방법
    • 권한 부여 URL
    • 콜백 URL - OIDC 콜백 URL 필드는 구성한 각 OIDC 공급자와 함께 서비스 공급자(SP)로 서비스를 등록합니다. 이 필드를 비워 둡니다. 이 인증 방법을 저장하면 자동으로 생성됩니다. 인증 흐름의 일부로 이 URL로의 리디렉션을 허용하도록 IdP를 구성합니다.
    • ID 키
    • ID 토큰 발행자
    • JWKS URI
    • OIDC 공개 키
    • 토큰 취소 방법 - 기본 방법은 GET 입니다.
    • 토큰 URL 취소
    • 응답 유형
    • 토큰 끝점 인증 방법
    • Userinfo URL
    • 사용자 이름 키
  8. OIDC 공급자 인증서 확인을 사용하여 OIDC 공급자 SSL/TLS 인증서 확인을 활성화하거나 비활성화합니다.
  9. 리디렉션 URI에서 state 매개변수를 활성화하거나 비활성화하려면 Redirect State를 사용합니다. 이를 통해 CSRF(Cross Site Request Forgery) 공격을 방지할 수 있습니다.
  10. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  11. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  12. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  13. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  14. 인증 메서드 생성을 클릭합니다.

2.5.9.1. 일반 OIDC Single Sign-On 인증 오류 문제 해결

OIDC JWT 알고리즘 설정이 명시적으로 정의되지 않은 경우 인증이 실패합니다. 인증 코드에는 허용되는 알고리즘 목록이 필요하며 OpenID Connect(OIDC) 구성 끝점에서 자동으로 검색되지 않습니다.

2.5.9.1.1. JWT_Algorithms 수동 구성

인증 실패를 해결하려면 플랫폼 게이트웨이 구성에서 지원되는 알고리즘 목록을 수동으로 제공합니다.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 목록에서 OIDC 인증기를 선택합니다.
  3. 인증 편집을 클릭하고 OIDC JWT 알고리즘 필드를 찾습니다.
  4. 지원되는 알고리즘 목록을 YAML 목록 또는 JSON 배열로 입력합니다. 이러한 알고리즘은 일반적으로 IdP의 OpenID Connect (OIDC) 검색 끝점에서 사용할 수 있습니다.

    [
        "PS384",
        "ES384",
        "RS384",
        "HS256",
        "HS512",
        "ES256",
        "RS256",
        "HS384",
        "ES512",
        "PS256",
        "PS512",
        "RS512"
    ]
  5. 변경 사항을 저장하십시오. 시스템은 토큰 확인을 위해 이러한 지정된 알고리즘을 사용하여 누락과 관련된 인증 오류를 해결합니다.
2.5.9.1.2. 엔터프라이즈 인증에 대한 디버깅 활성화

인증 문제를 추가로 진단하려면 플랫폼 게이트웨이에서 디버그 로깅을 활성화합니다.

프로세스

  1. 플랫폼 게이트웨이의 settings.py 파일에서 로깅 구성을 변경합니다.
  2. ansible_base 로거의 로깅 수준을 DEBUG:로 설정합니다.

    LOGGING['loggers']['ansible_base']['level'] = 'DEBUG'

    이 변경 후 로그에 자세한 AuthTokenError 메시지가 표시되어 오류 원인에 대한 특정 정보를 제공합니다.

2.5.9.1.3. 일반 OIDC 범위 불일치 문제 해결

IdM(Identity Provider)이 시스템에서 자동으로 추가되는 기본 범위를 지원하지 않으면 인증이 실패합니다.

시스템이 이 기본 범위를 추가하지 않도록 하려면 인증자 구성에 설정을 추가해야 합니다.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 목록에서 OIDC 인증기를 선택합니다.
  3. 인증 편집을 클릭합니다.
  4. additional Authenticator Fields 섹션에서 다음 속성 및 값을 추가합니다. 이 입력 상자는 YAML 또는 JSON을 지원합니다. 다른 필드가 있는 경우 새 행에 이 키-값 쌍을 추가해야 합니다.

    IGNORE_DEFAULT_SCOPE: True
  5. 변경 사항을 저장하십시오. 이제 인증자는 명시적으로 정의한 범위만 사용하므로 지원되지 않는 범위와 관련된 인증 실패를 해결합니다.

2.5.10. keycloak 인증 구성

Keycloak을 통합하여 사용자 인증을 관리하도록 Ansible Automation Platform을 구성할 수 있습니다.

참고

이 인증기를 사용하는 경우 Keycloak 인스턴스에 몇 가지 특정 설정이 필요합니다. 자세한 내용은 Python Keycloak 참조를 참조하십시오.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 Keycloak 을 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. Keycloak 액세스 토큰 URL 필드에서 사용자 토큰을 검색할 수 있는 위치를 입력합니다.
  6. 선택 사항: Keycloak 공급자 URL 필드의 로그인 흐름 중에 사용자가 가져온 리디렉션 위치를 입력합니다.
  7. Keycloak OIDC 키 필드에 Keycloak 설치의 클라이언트 ID를 입력합니다.
  8. Keycloak 공개 키 필드에 Keycloak 영역에서 제공하는 RS256 공개 키를 입력합니다.
  9. Keycloak OIDC 시크릿 필드에 Keycloak 설치의 OIDC 시크릿(Client Secret )을 입력합니다.
  10. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  11. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  12. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  13. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  14. 인증 메서드 생성을 클릭합니다.

문제 해결

jwt.exceptions.InvalidAudienceError: Audience가 일치하지 않는 경우 다음을 수행하여 대상을 다시 활성화해야 합니다.

  1. Keycloak 구성 탐색에서 클라이언트 범위 -CLIENT- ID-dedicated Add mapper Audience 를 선택합니다.
  2. 매퍼의 이름을 선택합니다.
  3. Included Client Audience에서 클라이언트에 해당하는 클라이언트 ID 를 선택합니다.

2.5.11. GitHub 인증 구성

OAuth를 사용하여 GitHub ID를 Ansible Automation Platform에 연결할 수 있습니다. GitHub 인증을 설정하려면 GitHub에 새 애플리케이션을 등록하여 GitHub에서 조직 소유 애플리케이션을 등록하여 OAuth2 키와 시크릿을 가져와야 합니다.

OAuth2 키(Client ID) 및 시크릿(Client Secret)은 UI에 필요한 필드를 제공하는 데 사용됩니다. 애플리케이션을 등록하려면 인증자 구성에 표시된 콜백 URL인 웹 페이지 URL을 제공해야 합니다. 이 정보에 액세스하는 방법에 대한 지침은 인증자 세부 정보 표시를 참조하십시오.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 GitHub 를 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. 애플리케이션이 등록되면 GitHub에 클라이언트 ID와 클라이언트 시크릿 이 표시됩니다.

    1. GitHub 클라이언트 ID를 복사하여 GitHub OAuth2 키 필드에 붙여넣습니다.
    2. GitHub 클라이언트 시크릿을 복사하여 GitHub OAuth2 시크릿 필드에 붙여넣습니다.
  6. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  7. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  8. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  9. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  10. 인증 메서드 생성을 클릭합니다.

검증

인증이 올바르게 구성되었는지 확인하려면 Ansible Automation Platform에서 로그아웃하고 로그인 화면에 해당 자격 증명으로 로그인할 수 있는 인증 선택한 방법의 로고가 표시되는지 확인합니다.

2.5.12. GitHub 조직 인증 구성

조직 또는 조직 내의 팀으로 계정 인증을 정의하는 경우 특정 조직 및 팀 설정을 사용해야 합니다. 조직 및 조직 내 팀에서 계정 인증을 제한할 수 있습니다.

조직 또는 팀 기반이 아닌 설정을 지정하여 모두 허용하도록 선택할 수도 있습니다. 조직 또는 조직 내 팀의 사용자만 제한하여 플랫폼에 로그인할 수 있는 사용자를 제한할 수 있습니다.

GitHub 조직에 대한 소셜 인증을 설정하려면 GitHub에 새 애플리케이션을 등록하여 웹 애플리케이션의 OAuth2 키와 시크릿을 가져와야 합니다.

OAuth2 키(Client ID) 및 시크릿(Client Secret)은 UI에 필요한 필드를 제공하는 데 사용됩니다. 애플리케이션을 등록하려면 인증자 구성에 표시된 콜백 URL인 웹 페이지 URL을 제공해야 합니다. 이 정보에 액세스하는 방법에 대한 지침은 인증자 세부 정보 표시를 참조하십시오.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 GitHub 조직을 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. 애플리케이션이 등록되면 GitHub에 클라이언트 ID와 클라이언트 시크릿 이 표시됩니다.

    1. GitHub 클라이언트 ID를 복사하여 GitHub OAuth2 키 필드에 붙여넣습니다.
    2. GitHub 클라이언트 시크릿을 복사하여 GitHub OAuth2 시크릿 필드에 붙여넣습니다.
  6. 조직의 URL에 사용된 대로 GitHub 조직의 이름을 입력합니다(예: GitHub OAuth 조직 이름 필드에 https://github.com/<yourorg>/ ).
  7. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  8. GitHub OAuth2 범위 필드에 사용자의 권한 부여 범위를 입력합니다. 기본값은 read:org 입니다.
  9. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  10. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  11. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  12. 인증 메서드 생성을 클릭합니다.

검증

인증이 올바르게 구성되었는지 확인하려면 Ansible Automation Platform에서 로그아웃하고 로그인 화면에 해당 자격 증명으로 로그인할 수 있는 인증 선택한 방법의 로고가 표시되는지 확인합니다.

2.5.13. GitHub 팀 인증 구성

GitHub 팀에 대한 소셜 인증을 설정하려면 GitHub에 새 애플리케이션을 등록하는 데 제공된 지침을 사용하여 웹 애플리케이션의 OAuth2 키와 시크릿을 가져와야 합니다.

OAuth2 키(Client ID) 및 시크릿(Client Secret)은 UI에 필요한 필드를 제공하는 데 사용됩니다. 애플리케이션을 등록하려면 인증자 구성에 표시된 콜백 URL인 웹 페이지 URL 을 제공해야 합니다. 이 정보에 액세스하는 방법에 대한 지침은 인증자 세부 정보 표시를 참조하십시오.

각 키와 시크릿은 고유한 애플리케이션에 속해야 하며 여러 인증 백엔드 간에 공유하거나 재사용할 수 없습니다. OAuth2 키(Client ID) 및 시크릿(Client Secret)은 UI에 필요한 필드를 제공하는 데 사용됩니다.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 GitHub 팀을 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. 애플리케이션이 등록되면 GitHub에 클라이언트 ID와 클라이언트 시크릿 이 표시됩니다.

    1. GitHub 클라이언트 ID를 복사하여 GitHub OAuth2 키 필드에 붙여넣습니다.
    2. GitHub 클라이언트 시크릿을 복사하여 GitHub OAuth2 시크릿 필드에 붙여넣습니다.
  6. GitHub OAuth2 팀 ID 필드에 GitHub의 팀 ID 를 복사하여 붙여넣습니다.
  7. GitHub OAuth2 범위 필드에 사용자의 권한 부여 범위를 입력합니다. 기본값은 read:org 입니다.
  8. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  9. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  10. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  11. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  12. 인증 메서드 생성을 클릭합니다.

    인증이 올바르게 구성되었는지 확인하려면 Ansible Automation Platform에서 로그아웃하고 로그인 화면에 해당 자격 증명으로 로그인할 수 있는 인증 선택한 방법의 로고가 표시되는지 확인합니다.

2.5.14. GitHub 엔터프라이즈 인증 구성

GitHub 엔터프라이즈에 대한 소셜 인증을 설정하려면 웹 애플리케이션의 GitHub Enterprise URL, API URL, OAuth2 키 및 시크릿을 가져와야 합니다.

URL을 가져오려면 GitHub Enterprise 관리 설명서 를 참조하십시오.

OAuth2 키(Client ID) 및 시크릿(Client Secret)은 UI에 필요한 필드를 제공하는 데 사용됩니다. 애플리케이션을 등록하려면 인증자 구성에 표시된 콜백 URL인 웹 페이지 URL 을 제공해야 합니다. 이 정보에 액세스하는 방법에 대한 지침은 인증자 세부 정보 표시를 참조하십시오.

각 키와 시크릿은 고유한 애플리케이션에 속해야 하며 여러 인증 백엔드 간에 공유하거나 재사용할 수 없습니다. OAuth2 키(Client ID) 및 시크릿(Client Secret)은 UI에 필요한 필드를 제공하는 데 사용됩니다.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 GitHub Enterprise 를 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. 애플리케이션이 등록되면 GitHub에 클라이언트 ID와 클라이언트 시크릿 이 표시됩니다.

    1. GitHub 클라이언트 ID를 복사하여 GitHub OAuth2 키 필드에 붙여넣습니다.
    2. GitHub 클라이언트 시크릿을 복사하여 GitHub OAuth2 시크릿 필드에 붙여넣습니다.
  6. 기본 URL 필드에 GitHub Enterprise 인스턴스의 호스트 이름을 입력합니다(예: https://github.example.com ).
  7. Github OAuth2 Enterprise API URL 필드에 GitHub Enterprise 인스턴스의 API URL을 입력합니다(예: https://github.example.com/api/v3 ).
  8. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  9. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  10. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  11. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  12. 인증 메서드 생성을 클릭합니다.

검증

인증이 올바르게 구성되었는지 확인하려면 Ansible Automation Platform에서 로그아웃하고 로그인 화면에 해당 자격 증명으로 로그인할 수 있는 인증 선택한 방법의 로고가 표시되는지 확인합니다.

2.5.15. GitHub 엔터프라이즈 조직 인증 구성

GitHub 엔터프라이즈 조직에 대한 소셜 인증을 설정하려면 GitHub 엔터프라이즈 조직 URL, 조직 API URL, 조직 OAuth2 키 및 웹 애플리케이션의 시크릿을 가져와야 합니다.

URL을 가져오려면 GitHub Enterprise 관리 설명서 를 참조하십시오.

OAuth2 키(Client ID) 및 시크릿(Client Secret)은 UI에 필요한 필드를 제공하는 데 사용됩니다. 애플리케이션을 등록하려면 인증자 구성에 표시된 콜백 URL인 웹 페이지 URL 을 제공해야 합니다. 이 정보에 액세스하는 방법에 대한 지침은 인증자 세부 정보 표시를 참조하십시오.

각 키와 시크릿은 고유한 애플리케이션에 속해야 하며 여러 인증 백엔드 간에 공유하거나 재사용할 수 없습니다. OAuth2 키(Client ID) 및 시크릿(Client Secret)은 UI에 필요한 필드를 제공하는 데 사용됩니다.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 GitHub Enterprise 조직을 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. 애플리케이션을 등록하면 GitHub에 클라이언트 ID와 클라이언트 시크릿 이 표시됩니다.

    1. GitHub 클라이언트 ID를 복사하여 GitHub OAuth2 키 필드에 붙여넣습니다.
    2. GitHub 클라이언트 시크릿을 복사하여 GitHub OAuth2 시크릿 필드에 붙여넣습니다.
  6. 기본 URL 필드에 GitHub Enterprise 인스턴스의 호스트 이름을 입력합니다(예: https://github.example.com ).
  7. Github OAuth2 Enterprise API URL 필드에 GitHub Enterprise 인스턴스의 API URL을 입력합니다(예: https://github.example.com/api/v3 ).
  8. 조직의 URL에 사용된 대로 GitHub 엔터프라이즈 조직의 이름을 입력합니다(예: GitHub OAuth2 엔터프라이즈 조직 이름 필드에 https://github.com/<yourorg>/ ).
  9. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  10. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  11. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  12. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  13. 인증 메서드 생성을 클릭합니다.

    인증이 올바르게 구성되었는지 확인하려면 Ansible Automation Platform에서 로그아웃하고 로그인 화면에 해당 자격 증명으로 로그인할 수 있는 인증 선택한 방법의 로고가 표시되는지 확인합니다.

2.5.16. GitHub 엔터프라이즈 팀 인증 구성

GitHub 엔터프라이즈 팀에 대한 소셜 인증을 설정하려면 GitHub Enterprise 조직 URL, 조직 API URL, 조직 OAuth2 키 및 웹 애플리케이션의 시크릿을 가져와야 합니다.

URL을 가져오려면 GitHub Enterprise 관리 설명서 를 참조하십시오.

키와 시크릿을 얻으려면 먼저 https://github.com/organizations/<yourorg>/settings/applications 에서 엔터프라이즈 조직 소유 애플리케이션을 등록해야 합니다.

OAuth2 키(Client ID) 및 시크릿(Client Secret)은 UI에 필요한 필드를 제공하는 데 사용됩니다. 애플리케이션을 등록하려면 인증자 구성에 표시된 콜백 URL인 웹 페이지 URL 을 제공해야 합니다. 이 정보에 액세스하는 방법에 대한 지침은 인증자 세부 정보 표시를 참조하십시오.

각 키와 시크릿은 고유한 애플리케이션에 속해야 하며 여러 인증 백엔드 간에 공유하거나 재사용할 수 없습니다. OAuth2key(Client ID) 및 시크릿(Client Secret)은 UI의 필수 필드를 제공하는 데 사용됩니다.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 GitHub 엔터프라이즈 팀을 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. 애플리케이션이 등록되면 GitHub에 클라이언트 ID와 클라이언트 시크릿 이 표시됩니다.

    1. GitHub 클라이언트 ID를 복사하여 GitHub OAuth2 키 필드에 붙여넣습니다.
    2. GitHub 클라이언트 시크릿을 복사하여 GitHub OAuth2 시크릿 필드에 붙여넣습니다.
  6. 기본 URL 필드에 GitHub Enterprise 인스턴스의 호스트 이름을 입력합니다(예: https://github.orgexample.com ).
  7. Github OAuth2 Enterprise API URL 필드에 GitHub Enterprise 인스턴스의 API URL을 입력합니다(예: https://github.example.com/api/v3 ).
  8. GitHub OAuth2 팀 ID 필드에 GitHub 개발자 애플리케이션의 OAuth2 키(Client ID)를 입력합니다.
  9. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  10. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  11. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  12. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  13. 인증 메서드 생성을 클릭합니다.

검증

인증이 올바르게 구성되었는지 확인하려면 Ansible Automation Platform에서 로그아웃하고 로그인 화면에 해당 자격 증명으로 로그인할 수 있는 인증 선택한 방법의 로고가 표시되는지 확인합니다.

2.5.17. RADIUS 인증 구성

RADIUS를 인증 정보 소스로 중앙에서 사용하도록 Ansible Automation Platform을 구성할 수 있습니다.

프로세스

  1. 탐색 패널에서 Access Management Authentication Methods 를 선택합니다.
  2. 인증 생성을 클릭합니다.
  3. 이 인증 구성 의 이름을 입력합니다.
  4. 인증 유형 목록에서 Radius 를 선택합니다. 인증 세부 정보 섹션은 선택한 인증 유형과 관련된 필드를 표시하도록 자동으로 업데이트됩니다.
  5. RADIUS 서버 필드에 RADIUS 서버의 호스트 또는 IP를 입력합니다. 이 필드를 비워 두면 RADIUS 인증이 비활성화됩니다.
  6. RADIUS 서버에 인증할 공유 시크릿을 입력합니다.
  7. 선택 사항: 이 인증기를 사용할 수 있는 추가 인증 필드를 입력합니다. 이러한 필드는 검증되지 않으며 인증기로 직접 전달됩니다.

    참고

    이 필드에 정의된 값은 UI에 제공된 전용 필드를 재정의합니다. 여기에 정의되지 않은 모든 값은 인증자에게 제공되지 않습니다.

  8. 성공적인 로그인 시 조직, 사용자 및 팀을 자동으로 생성하려면 Create objects 를 선택합니다.
  9. 생성 시 이 인증 방법을 활성화하려면 Enabled 를 선택합니다.
  10. 이 소스에서 인증할 때 이전에 추가한 그룹의 사용자를 제거하려면 사용자 제거를 선택합니다.
  11. 인증 메서드 생성을 클릭합니다.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동