이 섹션에서는 다음 엔터프라이즈 시스템에 대한 인증을 설정하는 방법을 설명합니다.
참고
LDAP 인증의 경우 :ref:`ag_auth_ldap`를 참조하십시오.
SAML, RADIUS, TACACS+ 사용자는 〈엔터프라이즈〉 사용자로 분류됩니다. 다음은 엔터프라이즈 사용자에게 적용되는 규칙입니다.
엔터프라이즈 사용자는 원격 인증 백엔드에서 처음 성공한 로그인 시도를 통해서만 생성할 수 있습니다.
동일한 이름의 엔터프라이즈 사용자가 이미 컨트롤러에 생성된 경우에는 엔터프라이즈 사용자를 생성/인증할 수 없습니다.
엔터프라이즈 사용자의 컨트롤러 암호는 항상 비어 있어야 하며, 활성화된 엔터프라이즈 백엔드가 있는 경우 어떤 사용자도 설정할 수 없습니다.
엔터프라이즈 백엔드가 비활성화된 경우 암호 필드를 설정하여 엔터프라이즈 사용자를 일반 컨트롤러 사용자로 변환할 수 있습니다. 그러나 변환된 컨트롤러 사용자는 더 이상 엔터프라이즈 사용자로 처리할 수 없으므로 이 작업은 되돌릴 수 없습니다.
Microsoft Azure AD(Active Directory)에 대한 엔터프라이즈 인증을 설정하려면 https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app 에서 Azure에서 조직 소유 애플리케이션을 등록하여 OAuth2 키와 시크릿을 가져와야 합니다. 각 키와 시크릿은 고유한 애플리케이션에 속해야 하며 여러 인증 백엔드 간에 공유하거나 재사용할 수 없습니다. 애플리케이션을 등록하려면 설정 인증 화면에 표시된 콜백 URL인 웹 페이지 URL을 제공해야 합니다.
왼쪽 탐색 모음에서 **설정**을 클릭합니다.
설정 창 왼쪽의 인증 옵션 목록에서 **Azure AD 설정**을 클릭합니다.
Azure AD OAuth2 콜백 URL 필드는 미리 채워져 있으며 편집할 수 없습니다. 애플리케이션이 등록되면 Azure에서 애플리케이션 ID와 오브젝트 ID를 표시합니다.
편집**을 클릭하고 Azure 애플리케이션 ID를 복사하여 **Azure AD OAuth2 키 필드에 붙여넣습니다.
앱을 Microsoft Azure Active Directory에 연결하는 방법에 대한 Azure AD 문서에 따라 인증용 키(한 번만 표시)를 클라이언트에 제공합니다.
Azure AD 애플리케이션에 대해 생성된 실제 시크릿 키를 복사하여 설정 - 인증 화면의 Azure AD OAuth2 시크릿 필드에 붙여넣습니다.
매핑 필드를 작성하는 방법에 대한 자세한 내용은 :ref:`ag_org_team_maps`를 참조하십시오.
완료되면 **저장**을 클릭합니다.
인증이 올바르게 구성되었는지 확인하려면 |at|에서 로그아웃합니다. 이제 로그인 화면에 Microsoft Azure 로고가 표시되어 해당 인증 정보를 사용한 로그인을 허용합니다.
Azure AD의 애플리케이션 등록 기본 사항은 Azure AD Identity Platform (v2) 개요를 참조하십시오.
LDAP 인증 설정 섹션을 참조하십시오.
중앙에서 RADIUS를 인증 정보 소스로 사용하도록 |at|를 구성할 수 있습니다.
SAML을 사용하면 ID 공급자(IdP - Single Sign On 서비스를 제공하는 서버 시스템)와 서비스 공급자(이 경우 automation controller) 간에 인증 및 권한 부여 데이터를 교환할 수 있습니다. 컨트롤러 사용자를 인증(생성/로그인/로그아웃)하기 위해 SAML과 통신하도록 |at|를 구성할 수 있습니다. 컨트롤러에 대한 SAML 응답에 사용자 팀 및 조직 멤버십을 포함할 수 있습니다.
다음 지침에서는 |at|를 서비스 공급자로 설명합니다. RHSSO(keycloak)를 통해 사용자를 인증하려면 Red Hat Single Sign On Integration with the Automation Controller 블로그를 참조하십시오.
SAML 인증을 설정하려면 다음을 수행합니다.
왼쪽 탐색 모음에서 **설정**을 클릭합니다.
설정 창 왼쪽의 인증 옵션 목록에서 **SAML 설정**을 클릭합니다.
SAML ACS(Assertion Consume Service) URL 및 SAML 서비스 공급자 메타데이터 URL 필드는 미리 채워져 있으며 편집할 수 없습니다. ID 공급자 관리자에게 연락하여 해당 필드에 포함된 정보를 제공합니다.
편집**을 클릭하고 **SAML 서비스 공급자 엔터티 ID**를 **컨트롤러 호스트의 기본 URL 필드와 동일하게 설정합니다. 이 필드는 왼쪽 탐색 모음에서 **설정**을 클릭하여 기타 시스템 설정 화면에서 찾을 수 있습니다. API를 통해 /api/v2/settings/system``의 ``CONTROLLER_BASE_URL
변수 아래에서 볼 수 있습니다. 엔터티 ID를 개별 컨트롤러 클러스터 노드 중 하나로 설정할 수 있지만, 서비스 공급자의 URL로 설정하는 것이 좋습니다. 기본 URL이 로드 밸런서의 FQDN과 일치하는지 확인합니다(사용되는 경우).
참고
기본 URL은 클러스터의 각 노드에 따라 다릅니다. 일반적으로 로드 밸런서는 여러 컨트롤러 클러스터 노드 앞에 배치되어 단일 진입점인 컨트롤러 클러스터 FQDN을 제공합니다. SAML 서비스 공급자는 SAML 서비스 공급자 엔터티 ID에 설정된 컨트롤러 클러스터 노드 또는 컨트롤러 클러스터 FQDN에 대한 아웃바운드 연결과 경로를 설정할 수 있어야 합니다.
이 예제에서는 서비스 공급자가 컨트롤러 클러스터이므로 ID가 컨트롤러 클러스터 FQDN으로 설정됩니다.
Ansible 클러스터에 대한 서버 인증서를 생성합니다. 일반적으로 Ansible 클러스터가 구성된 경우 컨트롤러 노드는 HTTP 트래픽만 처리하도록 구성되고 로드 밸런서가 SSL 종료 지점이 됩니다. 이 경우 로드 밸런서에 SSL 인증서가 필요하고 개별 컨트롤러 클러스터 노드에는 필요하지 않습니다. 개별 컨트롤러 노드별로 SSL을 활성화하거나 비활성화할 수 있지만 SSL 종료 로드 밸런서를 사용할 때는 비활성화해야 합니다. 정기적인 인증서 업데이트를 방지하기 위해 만료되지 않는 자체 서명 인증서를 사용하는 것이 좋습니다. 이렇게 하면 인증서 업데이트를 잊어버린 경우에도 인증이 실패하지 않습니다.
참고
SAML 서비스 공급자 공용 인증서 필드에는 《—–BEGIN CERTIFICATE—–》 및 《—–END CERTIFICATE—–《를 포함한 전체 인증서가 포함되어야 합니다.
인증서가 포함된 CA 번들을 사용하는 경우에는 이 필드에 전체 번들을 포함합니다.
공용 인증서의 예는 다음과 같습니다.
-----BEGIN CERTIFICATE——
... cert text ...
-----END CERTIFICATE——
SP(서비스 공급자)로 사용할 컨트롤러의 선택적 개인 키를 생성하고 SAML 서비스 공급자 개인 키 필드에 입력합니다.
개인 키의 예는 다음과 같습니다.
-----BEGIN PRIVATE KEY--
... key text ...
-----END PRIVATE KEY——
SAML 서비스 공급자 조직 정보 필드에서 SSO 프로세스 중 컨트롤러 클러스터에 대한 몇 가지 세부 정보를 IdP에 제공합니다.
{
"en-US": {
"url": "http://www.example.com",
"displayname": "Example",
"name": "example"
}
}
예를 들어 다음과 같습니다.
참고
이러한 필드는 컨트롤러 내에서 SAML을 올바르게 구성하기 위해 필요합니다.
SAML 서비스 공급자 기술 연락처 필드에서 기술 연락처 정보를 IdP에 제공합니다. 이 필드의 내용을 제거하지 마십시오.
{
"givenName": "Some User",
"emailAddress": "[email protected]"
}
예를 들어 다음과 같습니다.
SAML 서비스 공급자 지원 연락처 필드에서 지원 연락처 정보를 IdP에 제공합니다. 이 필드의 내용을 제거하지 마십시오.
{
"givenName": "Some User",
"emailAddress": "[email protected]"
}
예를 들어 다음과 같습니다.
SAML이 활성화된 ID 공급자 필드에서 나열된 각 ID 공급자에 연결하는 방법에 대한 정보를 제공합니다. 아래 예제에서 컨트롤러는 다음과 같은 SAML 속성을 예상합니다.
Username(urn:oid:0.9.2342.19200300.100.1.1)
Email(urn:oid:0.9.2342.19200300.100.1.3)
FirstName(urn:oid:2.5.4.42)
LastName(urn:oid:2.5.4.4)
이러한 속성을 알 수 없는 경우 기존 SAML 속성을 lastname, firstname, email, username에 매핑합니다.
각 IdP에 필요한 키를 구성합니다.
attr_user_permanent_id
- 사용자의 고유 식별자입니다. IdP에서 전송된 속성 중 하나와 일치하도록 구성할 수 있습니다. 일반적으로SAML:nameid
속성이 컨트롤러 노드로 전송되는 경우 ``name_id``로 설정되거나, username 속성 또는 사용자 지정 고유 식별자일 수 있습니다.
entity_id
- ID 공급자 관리자가 제공한 엔터티 ID입니다. 관리자는 컨트롤러에 대한 SAML 프로필을 생성하고 고유한 URL을 생성합니다.
url
- SSO가 활성화된 경우 컨트롤러에서 사용자를 리디렉션하는 SSO(Single Sign On) URL입니다.
x509_cert
- IdP 관리자가 제공한 인증서로, ID 공급자에 생성된 SAML 프로필에서 생성된 것입니다.--BEGIN CERTIFICATE--
및--END CERTIFICATE--
헤더를 제거한 다음, 줄 바꿈하지 않는 하나의 문자열로 인증서를 입력합니다.여러 SAML IdP가 지원됩니다. 일부 IdP는 기본 OID(https://github.com/omab/python-social-auth/blob/master/social/backends/saml.py)와 다른 속성 이름을 사용하여 사용자 데이터를 제공할 수 있습니다. SAML ``NameID``는 일부 ID 공급자가 서비스 공급자(컨트롤러 클러스터)에 고유한 사용자 식별자를 알리는 데 사용하는 특수 속성입니다. 이 속성이 사용되는 경우 예제에 표시된 대로 ``attr_user_permanent_id``를 ``name_id``로 설정합니다. 다음과 같이 각 IdP에 대해 다른 속성 이름을 덮어쓸 수 있습니다.
{
"myidp": {
"entity_id": "https://idp.example.com",
"url": "https://myidp.example.com/sso",
"x509cert": ""
},
"onelogin": {
"entity_id": "https://app.onelogin.com/saml/metadata/123456",
"url": "https://example.onelogin.com/trust/saml2/http-post/sso/123456",
"x509cert": "",
"attr_user_permanent_id": "name_id",
"attr_first_name": "User.FirstName",
"attr_last_name": "User.LastName",
"attr_username": "User.email",
"attr_email": "User.email"
}
}
경고
다른 사용자(비 SAML 사용자 포함)와 동일한 이메일을 공유하는 SAML 사용자를 생성하지 마십시오. 생성하면 계정이 병합됩니다. 시스템 관리자 사용자의 경우에도 동일한 동작이 있으므로 시스템 관리자 사용자와 동일한 이메일 주소를 사용하는 SAML 로그인은 시스템 관리자 권한으로 로그인됩니다. 나중에 참조하기 위해 후속 단계에 설명된 대로 SAML 매핑에 따라 관리자 권한을 제거(또는 추가)할 수 있습니다.
참고
IdP는 잘 알려진 SAML urn을 사용하여 이메일, 성, 이름을 제공합니다. IdP는 사용자 지정 SAML 속성을 사용하여 컨트롤러가 읽을 수 없는 속성인 사용자를 식별합니다. 대신, 컨트롤러는 URN이라는 고유 식별자 이름을 파악할 수 있습니다. 아래 예제와 같이 SAML 《Name》 속성에 나열된 URN을 사용자 속성에 사용합니다.
선택 사항으로 **SAML 조직 맵**을 제공합니다. 자세한 내용은 :ref:`ag_org_team_maps`를 참조하십시오.
컨트롤러에 로그인할 때 사용자와 연결할 팀 및 조직 멤버십이 포함된 특정 속성을 찾도록 컨트롤러를 구성할 수 있습니다. 속성 이름은 SAML 조직 속성 매핑 및 SAML 팀 속성 매핑 필드에서 정의됩니다.
SAML 조직 속성 매핑 예제
다음은 member-of 속성에 사용자 조직 멤버십을 포함하는 SAML 속성 예제입니다.
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="member-of" Name="member-of"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue>Engineering</saml2:AttributeValue>
<saml2:AttributeValue>IT</saml2:AttributeValue>
<saml2:AttributeValue>HR</saml2:AttributeValue>
<saml2:AttributeValue>Sales</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="admin-of" Name="admin-of"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue>Engineering</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
다음은 해당 컨트롤러 구성입니다.
{
"saml_attr": "member-of",
"saml_admin_attr": "admin-of",
"remove": true,
"remove_admins": false
}
saml_attr
: 조직 배열을 찾을 수 있는 SAML 속성 이름입니다. 조직 목록에 사용자를 추가하기 전에 모든 조직에서 해당 사용자를 제거하기 위해 ``remove``가 **True**로 설정되었습니다. SAML 속성의 조직에 사용자를 추가하는 동안 속해 있는 모든 조직에서 해당 사용자를 유지하려면 ``remove``를 **False**로 설정합니다.
saml_admin_attr
: saml_attr
속성과 유사하지만 이 속성은 조직 멤버십을 전달하는 대신 관리자 조직 권한을 전달합니다.
SAML 팀 속성 매핑 예제
다음은 목록에 팀 멤버십이 포함된 SAML 속성의 또 다른 예제입니다.
<saml:AttributeStatement>
<saml:Attribute
xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
x500:Encoding="LDAP"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
FriendlyName="eduPersonAffiliation">
<saml:AttributeValue
xsi:type="xs:string">member</saml:AttributeValue>
<saml:AttributeValue
xsi:type="xs:string">staff</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
{
"saml_attr": "eduPersonAffiliation",
"remove": true,
"team_org_map": [
{
"team": "member",
"organization": "Default1"
},
{
"team": "staff",
"organization": "Default2"
}
]
}
saml_attr
: 팀 배열을 찾을 수 있는 SAML 속성 이름입니다.
remove
: 팀 목록에 사용자를 추가하기 전에 모든 팀에서 해당 사용자를 제거하려면 ``remove``를 **True**로 설정합니다. SAML 속성의 팀에 사용자를 추가하는 동안 속해 있는 모든 팀에서 해당 사용자를 유지하려면 ``remove``를 **False**로 설정합니다.
team_org_map
: 컨트롤러 팀 -> 컨트롤러 조직의 매핑을 정의하는 { "team": "<AWX Team Name>", "organization": "<AWX Org Name>" }
형식의 사전 배열입니다. 동일한 이름의 팀이 컨트롤러의 여러 조직에 존재할 수 있기 때문에 필요합니다. 이 매핑이 없으면 SAML 속성에 나열된 팀이 속한 조직이 모호하게 됩니다.
별칭을 생성하여 **SAML 팀 속성 매핑**의 팀과 조직을 둘 다 덮어쓸 수 있습니다. 이 옵션은 SAML 백엔드에서 아래 예제와 같이 복잡한 그룹 이름을 전송하는 경우에 매우 편리합니다.
{
"remove": false,
"team_org_map": [
{
"team": "internal:unix:domain:admins",
"organization": "Default",
"team_alias": "Administrators"
},
{
"team": "Domain Users",
"organization_alias": "OrgAlias",
"organization": "Default"
}
],
"saml_attr": "member-of"
}
사용자가 인증되면 컨트롤러에서 예상대로 조직 및 팀 별칭을 생성합니다.
선택 사항으로 SAML 팀 맵 필드에서 팀 멤버십 매핑을 제공합니다. 자세한 내용은 :ref:`ag_org_team_maps`를 참조하십시오.
선택 사항으로 SAML 보안 구성 필드에서 보안 설정을 제공합니다. 이 필드는 API의 SOCIAL_AUTH_SAML_SECURITY_CONFIG
필드와 동일합니다. 자세한 내용은 `OneLogin’s SAML Python Toolkit`_을 참조하십시오.
사용자가 SAML을 통해 로그인하는 경우 컨트롤러는 python-social-auth
라이브러리를 사용합니다. 이 라이브러리는 python-saml
라이브러리를 사용하여 두 개의 선택적 필드인 **SAML 서비스 공급자 추가 구성 데이터**와 **SAML IDP-EXTRA_DATA 속성 매핑**에 대한 설정을 사용할 수 있게 합니다.
SAML 서비스 공급자 추가 구성 데이터 필드는 API의 SOCIAL_AUTH_SAML_SP_EXTRA``와 동일합니다. 유효한 서비스 공급자 추가(``SP_EXTRA
) 매개변수에 대한 자세한 내용은 `python-saml library documentation`_를 참조하십시오.
SAML IDP-EXTRA_DATA 속성 매핑 필드는 API의 ``SOCIAL_AUTH_SAML_EXTRA_DATA``와 동일합니다. 자세한 내용은 Python SAML Advanced Settings 문서를 참조하십시오.
SAML 사용자 플래그 속성 매핑 필드를 사용하여 SAML 역할 및 속성을 특수 사용자 플래그에 매핑할 수 있습니다. 다음 속성은 이 필드에서 유효합니다.
is_superuser_role
: 사용자에게 슈퍼유저 플래그를 부여할 SAML 역할을 지정합니다.
is_superuser_attr
: 사용자에게 슈퍼유저 플래그를 부여할 SAML 특성을 지정합니다.
is_superuser_value
: 사용자가 슈퍼유저가 되는 데 필요한 is_superuser_attr
에 필요한 특정 값을 지정합니다.
is_system_auditor_role
: 사용자에게 시스템 감사자 플래그를 부여할 SAML 역할을 지정합니다.
is_system_auditor_attr
: 시스템 감사자 플래그를 사용자에게 부여할 SAML 특성을 지정합니다.
is_system_auditor_value
: 사용자가 시스템 감사자가 되는 데 필요한 is_system_auditor_attr
에 필요한 특정 값을 지정합니다.
role
및 attr``이 모두 슈퍼유저 또는 system_auditor에 지정된 경우 ``attr
의 설정이 role
보다 우선합니다. 다음 표에서는 논리 작동 방식을 설명합니다.
역할이 있음 |
속성이 있음 |
속성 값이 있음 |
플래그 지정 |
---|---|---|---|
제공되지 않음 |
제공되지 않음 |
해당 없음 |
제공되지 않음 |
제공됨 |
제공되지 않음 |
해당 없음 |
제공됨 |
제공되지 않음 |
제공됨 |
제공됨 |
제공됨 |
제공되지 않음 |
제공됨 |
제공되지 않음 |
제공되지 않음 |
제공되지 않음 |
제공됨 |
설정되지 않음 |
제공됨 |
제공됨 |
제공됨 |
제공됨 |
제공됨 |
제공됨 |
제공됨 |
제공되지 않음 |
제공되지 않음 |
제공됨 |
제공됨 |
설정되지 않음 |
제공됨 |
완료되면 **저장**을 클릭합니다.
인증이 올바르게 구성되었는지 확인하려면 **SAML 서비스 공급자 메타데이터 URL**에 있는 자동 생성된 URL을 브라우저에 로드합니다. XML 출력이 표시되어야 합니다. 그렇지 않으면 올바르게 구성되지 않은 것입니다.
또는 |at|에서 로그아웃하면 이제 SAML 로고가 표시되어 SAML이 |at|에 로그인하는 대체 방법임을 나타냅니다.
투명한 로그인이 작동하려면 먼저 IdP 시작 로그인이 실행되어야 합니다. 이렇게 하려면 다음을 수행합니다.
이전에 설명한 대로 IdP의 RelayState``를 ``SAML Enabled Identity Providers
필드의 IdP 정의 키로 설정합니다. 위에 제공된 예제에서 RelayState``는 ``myidp
또는 ``onelogin``이어야 합니다.
제대로 실행되면, 왼쪽 탐색 모음에서 액세스할 수 있는 설정 메뉴의 기타 인증 설정 창에 있는 로그인 리디렉션 덮어쓰기 URL 필드를 사용하여 로그인하지 않은 사용자의 리디렉션 URL을 기본 컨트롤러 로그인 페이지 이외의 위치로 지정합니다. 예제에 표시된 대로, 투명한 SAML 로그인을 위해 ``/sso/login/saml/?idp=<name-of-your-idp>``로 설정해야 합니다.
참고
위의 형식은 일반적인 IdP 형식의 샘플이지만 특정 사례에 적합한 형식은 아닐 수 있습니다. 올바른 투명한 리디렉션 URL이 모든 IdP에서 동일하지는 않으므로 IdP에 해당 URL을 문의해야 할 수 있습니다.
LDAP에 대한 로깅을 활성화할 수 있는 방식과 동일하게 SAML 어댑터의 로깅 메시지를 활성화할 수 있습니다. LDAP에 로깅 활성화 섹션을 참조하십시오.
TACACS+(Terminal Access Controller Access-Control System Plus)는 중앙 집중식 서버를 통한 네트워크 액세스 제어를 위해 원격 인증 및 관련 서비스를 처리하는 프로토콜입니다. 특히 TACACS+는 AAA(인증, 권한 부여, 회계) 서비스를 제공하며, 이 서비스에서 인증 소스로 사용할 |at|를 구성할 수 있습니다.
참고
이 기능은 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다.
TACACS+ 서버: 인증에 사용할 TACACS+ 서버의 호스트 이름 또는 IP 주소를 제공합니다. 이 필드를 비워 두면 TACACS+ 인증이 비활성화됩니다.
TACACS+ 포트: TACACS+는 기본적으로 미리 채워져 있는 포트 49를 사용합니다.
TACACS + 시크릿: TACACS+ 인증 서버의 시크릿 키입니다.
TACACS+ 인증 세션 시간 초과: 초 단위의 세션 시간 초과 값입니다. 기본값은 5초입니다.
TACACS+ 인증 프로토콜: TACACS+ 클라이언트에서 사용하는 프로토콜입니다. 옵션은 ascii 또는 **pap**입니다.
완료되면 **저장**을 클릭합니다.