22. 엔터프라이즈 인증 설정¶

22.1. Azure AD 설정¶

Microsoft Azure AD(Active Directory)에 대한 엔터프라이즈 인증을 설정하려면 https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app 에서 Azure에서 조직 소유 애플리케이션을 등록하여 OAuth2 키와 시크릿을 가져와야 합니다. 각 키와 시크릿은 고유한 애플리케이션에 속해야 하며 여러 인증 백엔드 간에 공유하거나 재사용할 수 없습니다. 애플리케이션을 등록하려면 설정 인증 화면에 표시된 콜백 URL인 웹 페이지 URL을 제공해야 합니다.

1. 왼쪽 탐색 모음에서 **설정**을 클릭합니다.

2. 설정 창 왼쪽의 인증 옵션 목록에서 **Azure AD 설정**을 클릭합니다.

3. Azure AD OAuth2 콜백 URL 필드는 미리 채워져 있으며 편집할 수 없습니다. 애플리케이션이 등록되면 Azure에서 애플리케이션 ID와 오브젝트 ID를 표시합니다.

4. 편집**을 클릭하고 Azure 애플리케이션 ID를 복사하여 **Azure AD OAuth2 키 필드에 붙여넣습니다.

   앱을 Microsoft Azure Active Directory에 연결하는 방법에 대한 Azure AD 문서에 따라 인증용 키(한 번만 표시)를 클라이언트에 제공합니다.

5. Azure AD 애플리케이션에 대해 생성된 실제 시크릿 키를 복사하여 설정 - 인증 화면의 Azure AD OAuth2 시크릿 필드에 붙여넣습니다.

6. 매핑 필드를 작성하는 방법에 대한 자세한 내용은 :ref:`ag_org_team_maps`를 참조하십시오.

7. 완료되면 **저장**을 클릭합니다.

8. 인증이 올바르게 구성되었는지 확인하려면 |at|에서 로그아웃합니다. 이제 로그인 화면에 Microsoft Azure 로고가 표시되어 해당 인증 정보를 사용한 로그인을 허용합니다.

Azure AD의 애플리케이션 등록 기본 사항은 Azure AD Identity Platform (v2) 개요를 참조하십시오.

22.2. LDAP 인증¶

LDAP 인증 설정 섹션을 참조하십시오.

22.3. RADIUS 설정¶

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

1. 왼쪽 탐색 모음에서 **설정**을 클릭합니다.

2. 설정 창 왼쪽의 인증 옵션 목록에서 **RADIUS 설정**을 클릭합니다.

3. 편집**을 클릭하고 **RADIUS 서버 필드에 Radius 서버의 호스트 또는 IP를 입력합니다. 이 필드를 비워 두면 Radius 인증이 비활성화됩니다.

4. 다음 두 필드에 포트 및 시크릿 정보를 입력합니다.

5. 완료되면 **저장**을 클릭합니다.

22.4. SAML 설정¶

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 인증을 설정하려면 다음을 수행합니다.

1. 왼쪽 탐색 모음에서 **설정**을 클릭합니다.

2. 설정 창 왼쪽의 인증 옵션 목록에서 **SAML 설정**을 클릭합니다.

3. SAML ACS(Assertion Consume Service) URL 및 SAML 서비스 공급자 메타데이터 URL 필드는 미리 채워져 있으며 편집할 수 없습니다. ID 공급자 관리자에게 연락하여 해당 필드에 포함된 정보를 제공합니다.

4. 편집**을 클릭하고 **SAML 서비스 공급자 엔터티 ID**를 **컨트롤러 호스트의 기본 URL 필드와 동일하게 설정합니다. 이 필드는 왼쪽 탐색 모음에서 **설정**을 클릭하여 기타 시스템 설정 화면에서 찾을 수 있습니다. API를 통해 /api/v2/settings/system``의 ``CONTROLLER_BASE_URL 변수 아래에서 볼 수 있습니다. 엔터티 ID를 개별 컨트롤러 클러스터 노드 중 하나로 설정할 수 있지만, 서비스 공급자의 URL로 설정하는 것이 좋습니다. 기본 URL이 로드 밸런서의 FQDN과 일치하는지 확인합니다(사용되는 경우).

이 예제에서는 서비스 공급자가 컨트롤러 클러스터이므로 ID가 컨트롤러 클러스터 FQDN으로 설정됩니다.

5. Ansible 클러스터에 대한 서버 인증서를 생성합니다. 일반적으로 Ansible 클러스터가 구성된 경우 컨트롤러 노드는 HTTP 트래픽만 처리하도록 구성되고 로드 밸런서가 SSL 종료 지점이 됩니다. 이 경우 로드 밸런서에 SSL 인증서가 필요하고 개별 컨트롤러 클러스터 노드에는 필요하지 않습니다. 개별 컨트롤러 노드별로 SSL을 활성화하거나 비활성화할 수 있지만 SSL 종료 로드 밸런서를 사용할 때는 비활성화해야 합니다. 정기적인 인증서 업데이트를 방지하기 위해 만료되지 않는 자체 서명 인증서를 사용하는 것이 좋습니다. 이렇게 하면 인증서 업데이트를 잊어버린 경우에도 인증이 실패하지 않습니다.

인증서가 포함된 CA 번들을 사용하는 경우에는 이 필드에 전체 번들을 포함합니다.

공용 인증서의 예는 다음과 같습니다.

-----BEGIN CERTIFICATE——
... cert text ...
-----END CERTIFICATE——

6. SP(서비스 공급자)로 사용할 컨트롤러의 선택적 개인 키를 생성하고 SAML 서비스 공급자 개인 키 필드에 입력합니다.

개인 키의 예는 다음과 같습니다.

-----BEGIN PRIVATE KEY--
... key text ...
-----END PRIVATE KEY——

7. SAML 서비스 공급자 조직 정보 필드에서 SSO 프로세스 중 컨트롤러 클러스터에 대한 몇 가지 세부 정보를 IdP에 제공합니다.

{
  "en-US": {
    "url": "http://www.example.com",
    "displayname": "Example",
    "name": "example"
  }
}

예를 들어 다음과 같습니다.

8. SAML 서비스 공급자 기술 연락처 필드에서 기술 연락처 정보를 IdP에 제공합니다. 이 필드의 내용을 제거하지 마십시오.

{
"givenName": "Some User",
"emailAddress": "[email protected]"
}

예를 들어 다음과 같습니다.

9. SAML 서비스 공급자 지원 연락처 필드에서 지원 연락처 정보를 IdP에 제공합니다. 이 필드의 내용을 제거하지 마십시오.

{
"givenName": "Some User",
"emailAddress": "[email protected]"
}

예를 들어 다음과 같습니다.

10. 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"
  }
}

참고

IdP는 잘 알려진 SAML urn을 사용하여 이메일, 성, 이름을 제공합니다. IdP는 사용자 지정 SAML 속성을 사용하여 컨트롤러가 읽을 수 없는 속성인 사용자를 식별합니다. 대신, 컨트롤러는 URN이라는 고유 식별자 이름을 파악할 수 있습니다. 아래 예제와 같이 SAML 《Name》 속성에 나열된 URN을 사용자 속성에 사용합니다.

11. 선택 사항으로 **SAML 조직 맵**을 제공합니다. 자세한 내용은 :ref:`ag_org_team_maps`를 참조하십시오.

12. 컨트롤러에 로그인할 때 사용자와 연결할 팀 및 조직 멤버십이 포함된 특정 속성을 찾도록 컨트롤러를 구성할 수 있습니다. 속성 이름은 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"
}

사용자가 인증되면 컨트롤러에서 예상대로 조직 및 팀 별칭을 생성합니다.

13. 선택 사항으로 SAML 팀 맵 필드에서 팀 멤버십 매핑을 제공합니다. 자세한 내용은 :ref:`ag_org_team_maps`를 참조하십시오.

14. 선택 사항으로 SAML 보안 구성 필드에서 보안 설정을 제공합니다. 이 필드는 API의 SOCIAL_AUTH_SAML_SECURITY_CONFIG 필드와 동일합니다. 자세한 내용은 `OneLogin’s SAML Python Toolkit`_을 참조하십시오.

사용자가 SAML을 통해 로그인하는 경우 컨트롤러는 python-social-auth 라이브러리를 사용합니다. 이 라이브러리는 python-saml 라이브러리를 사용하여 두 개의 선택적 필드인 **SAML 서비스 공급자 추가 구성 데이터**와 **SAML IDP-EXTRA_DATA 속성 매핑**에 대한 설정을 사용할 수 있게 합니다.

15. SAML 서비스 공급자 추가 구성 데이터 필드는 API의 SOCIAL_AUTH_SAML_SP_EXTRA``와 동일합니다. 유효한 서비스 공급자 추가(``SP_EXTRA) 매개변수에 대한 자세한 내용은 `python-saml library documentation`_를 참조하십시오.

16. SAML IDP-EXTRA_DATA 속성 매핑 필드는 API의 ``SOCIAL_AUTH_SAML_EXTRA_DATA``와 동일합니다. 자세한 내용은 Python SAML Advanced Settings 문서를 참조하십시오.

17. SAML 사용자 플래그 속성 매핑 필드를 사용하여 SAML 역할 및 속성을 특수 사용자 플래그에 매핑할 수 있습니다. 다음 속성은 이 필드에서 유효합니다.

• is_superuser_role: 사용자에게 슈퍼유저 플래그를 부여할 하나 이상의 SAML 역할을 지정합니다.

• is_superuser_attr: 사용자에게 슈퍼유저 플래그를 부여할 SAML 특성을 지정합니다.

• is_superuser_value: 사용자가 슈퍼유저가 되는 데 필요한 is_superuser_attr 에 필요한 하나 이상의 값을 지정합니다.

• remove_superusers: 사용자를 위해 슈퍼 유저 플래그를 제거해야 하는지를 나타내는 부울입니다. 기본값은 ``true``입니다. (자세한 내용은 아래를 참조하십시오.)

• is_system_auditor_role: 사용자에게 시스템 감사자 플래그를 부여할 하나 이상의 SAML 역할을 지정합니다.

• is_system_auditor_attr: 시스템 감사자 플래그를 사용자에게 부여할 SAML 특성을 지정합니다.

• is_system_auditor_value: 사용자가 시스템 감사자가 되는 데 필요한 ``is_system_auditor_attr``에 하나 이상의 값을 지정합니다.

• remove_system_auditors: 사용자가 system_auditor 플래그를 제거해야 하는지를 나타내는 부울입니다. 기본값은 ``true``입니다. (자세한 내용은 아래를 참조하십시오.)

role 및 value 필드는 목록이며 or 논리입니다. 따라서 두 가지 역할 [ 《Role 1》, 《Role 2》 ] 중 하나를 지정하면 로직은 SAML 사용자에게 플래그에 필요한 역할이 있다고 간주합니다. 이는 value 필드에서도 마찬가지입니다, [ 《Value 1》, 《Value 2》] 값을 직정하면 SAML 사용자에게 속성 값이 둘 다 있는 경우 로직은 해당 속성 값이 일치하는 것으로 간주합니다.

role 및 attr``이/가 모두 ``superuser 또는 system_auditor``에 지정된 경우 ``attr``의 설정이 ``role``보다 우선됩니다.  시스템 관리자 및 시스템 감시자 역할은 SAML 사용자의 로그인 시 평가됩니다. SAML 설정이 아닌 UI를 통해 SAML 사용자에게 이러한 역할 중 하나를 부여할 경우 ``remove 플래그가 false로 설정되어 있지 않으면 사용자의 다음 로그인에서 역할이 제거됩니다. ``false``인 경우 제거 플래그는 SAML 어댑터가 해당 플래그를 사용자로 부터 제거할 수 없습니다. 다음 표에서는 논리 작동 방식을 설명합니다.

SAML 사용자가 |at|을/를 인증할 때마다 이러한 검사가 수행되고 필요에 따라 사용자 플래그가 변경됩니다. UI 내에서 SAML 사용자에 대해 System Administrator 또는 System Auditor``이/가 설정된 경우 SAML 어댑터는 위의 규칙에 따라 UI 설정을 재정의합니다. SAML 사용자가 로그인할 때 SAML 사용자의 사용자 플래그가 제거되지 않도록 하려면 ``remove_ 플래그를 ``false``로 설정할 수 있습니다. 제거 플래그를 ``false``로 설정하면 UI, API 또는 SAML 어댑터를 통해 ``true``로 설정된 사용자 플래그가 제거되지 않습니다. 그러나 사용자에게 플래그가 없고 위의 규칙에서 플래그를 추가해야 한다고 결정하는 경우 플래그가 ``false``인 경우에도 추가됩니다.

예:

{
    "is_superuser_attr": "blueGroups",
    "is_superuser_role": ["is_superuser"],
    "is_superuser_value": ["cn=My-Sys-Admins,ou=memberlist,ou=mygroups,o=myco.com"],
    "is_system_auditor_attr": "blueGroups",
    "is_system_auditor_role": ["is_system_auditor"],
    "is_system_auditor_value": ["cn=My-Auditors,ou=memberlist,ou=mygroups,o=myco.com"]
}

18. 완료되면 **저장**을 클릭합니다.

19. 인증이 올바르게 구성되었는지 확인하려면 **SAML 서비스 공급자 메타데이터 URL**에 있는 자동 생성된 URL을 브라우저에 로드합니다. XML 출력이 표시되어야 합니다. 그렇지 않으면 올바르게 구성되지 않은 것입니다.

    또는 |at|에서 로그아웃하면 이제 SAML 로고가 표시되어 SAML이 |at|에 로그인하는 대체 방법임을 나타냅니다.

    

22.4.1. 투명한 SAML 로그인¶

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

1. 이전에 설명한 대로 IdP의 RelayState``를 ``SAML Enabled Identity Providers 필드의 IdP 정의 키로 설정합니다. 위에 제공된 예제에서 RelayState``는 ``myidp 또는 ``onelogin``이어야 합니다.

2. 제대로 실행되면, 왼쪽 탐색 모음에서 액세스할 수 있는 설정 메뉴의 기타 인증 설정 창에 있는 로그인 리디렉션 덮어쓰기 URL 필드를 사용하여 로그인하지 않은 사용자의 리디렉션 URL을 기본 컨트롤러 로그인 페이지 이외의 위치로 지정합니다. 예제에 표시된 대로, 투명한 SAML 로그인을 위해 ``/sso/login/saml/?idp=<name-of-your-idp>``로 설정해야 합니다.

참고

위의 형식은 일반적인 IdP 형식의 샘플이지만 특정 사례에 적합한 형식은 아닐 수 있습니다. 올바른 투명한 리디렉션 URL이 모든 IdP에서 동일하지는 않으므로 IdP에 해당 URL을 문의해야 할 수 있습니다.

3. 투명한 SAML 로그인을 구성한 후 로컬 인증 정보 또는 다른 SSO를 사용하여 로그인하려면 ``https://<your-tower-server>/login``으로 직접 이동합니다. 그러면 SSO 인증 버튼을 포함하는 표준 컨트롤러 로그인 페이지가 제공되고, 구성된 방법 중 하나로 로그인할 수 있습니다.

22.5. TACACS + 설정¶

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

1. 왼쪽 탐색 모음에서 **설정**을 클릭합니다.

2. 설정 창 왼쪽의 인증 옵션 목록에서 **TACACS+ 설정**을 클릭합니다.

3. **편집**을 클릭하고 다음 필드에 정보를 입력합니다.

• TACACS+ 서버: 인증에 사용할 TACACS+ 서버의 호스트 이름 또는 IP 주소를 제공합니다. 이 필드를 비워 두면 TACACS+ 인증이 비활성화됩니다.

• TACACS+ 포트: TACACS+는 기본적으로 미리 채워져 있는 포트 49를 사용합니다.

• TACACS + 시크릿: TACACS+ 인증 서버의 시크릿 키입니다.

• TACACS+ 인증 세션 시간 초과: 초 단위의 세션 시간 초과 값입니다. 기본값은 5초입니다.

• TACACS+ 인증 프로토콜: TACACS+ 클라이언트에서 사용하는 프로토콜입니다. 옵션은 ascii 또는 **pap**입니다.

4. 완료되면 **저장**을 클릭합니다.

22.6. Generic OIDC settings¶

Similar to SAML, OpenID Connect (OIDC) is uses the OAuth 2.0 framework. It allows third-party applications to verify the identity and obtain basic end-user information. The main difference between OIDC and SMAL is that SAML has a service provider (SP)-to-IdP trust relationship, whereas OIDC establishes the trust with the channel (HTTPS) that is used to obtain the security token. To obtain the credentials needed to setup OIDC with controller, refer to the documentation from the identity provider (IdP) of your choice that has OIDC support.

To configure OIDC in controller:

1. 왼쪽 탐색 모음에서 **설정**을 클릭합니다.

2. On the left side of the Settings window, click Generic OIDC settings from the list of Authentication options.

3. **편집**을 클릭하고 다음 필드에 정보를 입력합니다.

• OIDC Key: Client ID from your 3rd-party IdP.

• OIDC Secret: Client Secret from your IdP.

• OIDC Provider URL: URL for your OIDC provider.

• Verify OIDC Provider Certificate: Use the toggle to enable/disable the OIDC provider SSL certificate verification.

The example below shows specific values associated to GitHub as the generic IdP:

4. 완료되면 **저장**을 클릭합니다.

5. To verify that the authentication was configured correctly, logout of automation controller and the login screen will now display the OIDC logo to indicate it as a alternate method of logging into automation controller.