인증 제공자 구성

Ping64에서 인증 제공자는 업무용 애플리케이션의 인증 연결 매개변수를 구성합니다. ID 관리는 OAuth 2.0 / OpenID Connect(OIDC)를 통한 애플리케이션 인증을 지원합니다. 제공자를 구성한 후 애플리케이션에 연결하고 업무용 애플리케이션 측에서도 설정과 검증을 완료해야 합니다.

인증 제공자와 디렉터리 ID 소스는 용도가 다릅니다. ID 소스는 ID 데이터에 연결하거나 이를 관리하고, 인증 제공자는 애플리케이션 인증 연결에 사용됩니다. 제공자를 저장했다고 해서 연결이 완료되거나 모든 사용자가 애플리케이션에 접근할 수 있는 것은 아닙니다.

이 문서에서 굵게 표시한 화면 항목은 영어 인터페이스를 기준으로 합니다. 다른 표시 언어에서는 실제 항목명이 다를 수 있습니다.

대상 애플리케이션에 요구 사항에 맞는 제공자가 이미 연결되어 있으면 먼저 확인하고 유지합니다. 아직 연결되지 않았다면 설정이 적절하고 다른 애플리케이션이 사용하지 않는 기존 제공자를 선택할 수 있습니다. 제공자 하나를 여러 애플리케이션에 동시에 연결할 수 없으므로 다른 애플리케이션이 사용 중이면 적합한 제공자를 별도로 준비하고 영향 평가 없이 기존 연결을 해제하지 마십시오. 인증 설정을 바꾸기 전에 애플리케이션 의존성과 복구 방안도 확인합니다.

구성 전 준비

• ID 관리 조회 및 구성 권한이 있는 관리자 계정을 사용합니다. 제공자를 삭제하려면 해당 작업 권한이 필요합니다.
• 애플리케이션 담당자와 클라이언트 유형, 로그인 콜백 주소, 로그아웃 후 리디렉션 주소, 필요한 범위와 사용자 식별자 요구사항을 확인합니다.
• ID 관리의 Certificates에서 사용할 서명 키를 준비하고, 테스트 애플리케이션과 접근 권한이 있는 계정 및 없는 계정을 준비합니다.
• Client Secret은 민감한 인증 정보입니다. 조직에서 승인한 안전한 경로로 보관하고 전달하며, 일반적인 업무 요청, 스크린샷 또는 공개 문서에 기록하지 않습니다.

제공자 만들기

1. IAM > Authentication Configuration > Authentication Providers: 콘솔에서 ID 관리로 전환하고 Authentication Configuration의 Authentication Providers를 연 다음 Create를 선택합니다.
2. Basic Information에 이름을 입력하고 필요하면 설명을 입력합니다. 이름은 필수입니다.
3. Protocol Settings에서 Client Type을 선택합니다. Confidential은 Client Secret을 안전하게 저장할 수 있는 애플리케이션에 적합하고, Public은 공유 Secret을 안전하게 저장할 수 없는 클라이언트에 적합합니다. 새 제공자의 기본 선택은 Confidential이며, 실제 연결 방식에 따라 확인해야 합니다.
4. 자동 생성된 Client ID를 확인합니다. 기밀 클라이언트에는 Client Secret도 표시됩니다. ID 또는 Secret을 다시 생성하기 전 애플리케이션 접근에 미치는 영향을 평가하고 새 인증 정보를 안전하게 전달합니다.
5. Redirect URI를 최소 1개, 최대 10개 입력합니다. 각 주소는 http:// 또는 https://로 시작해야 하며 애플리케이션이 실제로 사용하는 로그인 콜백 주소와 일치해야 합니다. 필요하면 Logout Redirect URI를 최대 10개 추가합니다.
6. 사용할 수 있는 Signing Key를 선택합니다. Advanced Protocol Settings에서 Scope, Subject Mode, Issuer Mode를 선택하고 애플리케이션 담당자와 확인합니다. Scope는 애플리케이션이 요청하는 ID 정보의 범위를 제한하고 Subject Mode는 애플리케이션이 받는 사용자 식별자에 영향을 줍니다. 불필요한 Scope는 부여하지 않습니다.
7. 저장한 후 성공 또는 실패 메시지를 확인합니다. 목록으로 돌아간 것만으로 저장 성공을 보장할 수 없습니다. 제공자를 다시 열어 이름, Client ID, 콜백 주소와 기타 설정을 확인합니다.

애플리케이션이 실제 사용하는 로그인 콜백의 전체 주소를 경로, 끝의 슬래시 및 쿼리 매개변수를 포함하여 등록합니다. 인증 요청과 인증 코드 교환에도 같은 콜백 주소를 사용하며 도메인만 입력해서는 안 됩니다. 애플리케이션이 로그아웃 후 이동을 요청한다면 먼저 해당 전체 주소를 Logout Redirect URI에 등록합니다. 등록되지 않은 주소는 거부됩니다. 로그아웃 후 이동을 사용하지 않으면 주소를 추가할 필요가 없습니다.

설정 화면에서 http:// 주소를 허용하더라도 운영 환경에 적합하거나 네트워크 전송이 보호된다는 뜻은 아닙니다. 조직의 보안 요구사항에 따라 전송 방식과 콜백 주소를 평가합니다.

범위 선택 및 검증: 페이지에는 openid, profile, email, offline_access가 있습니다. 여기서 선택하는 것은 애플리케이션이 요청할 수 있는 허용 범위이며, 애플리케이션도 로그인 요청에서 필요한 범위를 실제로 요청해야 합니다. 요청에는 하나 이상의 범위가 있어야 하고 허용 범위를 초과할 수 없습니다. OIDC 로그인에는 연동 요구 사항에 따라 openid를 선택하십시오. 사용자 정보에서 이름 또는 이메일을 가져오려면 각각 profile 또는 email이 허용되고 실제로 요청되는지 확인하십시오. 이메일 정보는 계정에 이메일이 입력되어 있는지도 영향을 받습니다. offline_access는 갱신 토큰과 관련되지만 선택만으로 갱신을 보장하지는 않습니다. 이 페이지에서 저장한 설정은 갱신 토큰 방식을 허용하지 않습니다. 검색 정보나 갱신 토큰 수신만으로 이후 갱신이 성공한다고 판단하지 마십시오. 지속 로그인이 필요하면 애플리케이션 담당자 및 기술 지원과 가능한 방안을 확인하고 운영 전에 토큰 만료 후 동작을 검증하십시오.

애플리케이션 연결 및 검증

기존 공급자가 요구 사항에 맞고 대상 애플리케이션에 이미 연결되어 있으면 1단계와 2단계를 건너뛰고 3단계부터 확인한 뒤 검증을 계속합니다. 애플리케이션을 새로 만들거나 연결을 변경해야 할 때만 1단계와 2단계를 수행합니다. 변경 전에 다른 애플리케이션과 사용자에 미치는 영향을 평가하고 복구 방안을 준비합니다.

1. Applications & Access에서 Applications를 열고 애플리케이션을 만들거나 기존 항목을 편집합니다.
2. 애플리케이션 설정의 제공자 필드에서 선택 창을 열고 적용 가능하고 사용 가능한 제공자를 선택합니다. 다른 필수 설정을 완료한 뒤 저장합니다. 실제 사용 요구에 맞게 접근 범위를 구성해야 하며, 제공자를 연결한 것만으로 사용자 접근 권한이 부여되지는 않습니다.
3. Authentication Providers로 돌아가 제공자 이름을 선택해 상세 정보를 열고 연결된 애플리케이션, Client ID, 콜백 주소 및 표시된 OpenID 구성 정보를 확인합니다.
4. 먼저 업무용 애플리케이션의 연결 매개변수를 확인하고 요구 사항에 맞지 않는 경우에만 애플리케이션 담당자가 승인된 계획에 따라 조정합니다. 통제된 테스트 계정으로 접근이 허용되는 경우와 거부되는 경우를 각각 검증하고 로그인 및 로그아웃 후 실제 리디렉션을 확인합니다.
5. 요청된 Scope, 사용자 식별자와 서명 검증이 예상대로인지 확인합니다. Issuer Mode는 실제 검색 문서, 토큰 및 연동 테스트 결과와 함께 확인하고 화면의 선택 항목 설명만으로 실제 발급자를 판단하지 않습니다.
6. 애플리케이션 담당자와 인증 코드 방식을 사용하는지 확인합니다. 기밀 클라이언트가 Secret을 사용한다면 안전한 경로로 양측 설정이 일치하는지 확인합니다. 공개 클라이언트는 PKCE를 지원하고 인증 요청과 인증 코드 교환에 서로 맞는 검증 매개변수를 사용해야 하며, S256을 우선 사용합니다. PKCE를 지원하지 않거나 매개변수가 일치하지 않으면 인증이 실패할 수 있습니다. Secret을 안전하게 저장할 수 없는 제약을 우회하려고 기밀 클라이언트로 변경하지 마십시오.

수정 및 삭제

제공자 목록에서 대상의 Edit를 선택해 설정을 변경할 수 있습니다. 편집 중 Secret을 다시 생성하지 않으면 화면에 마스크가 표시될 수 있으므로 이를 실제 Secret으로 사용하지 않습니다. Client ID, Secret, 리디렉션 URI, 서명 키 또는 사용자 식별자 모드를 변경하면 연결된 애플리케이션에 영향을 줄 수 있습니다. 변경 전에 작업 시간과 복구 계획을 마련하고 변경 후 연결된 애플리케이션을 다시 검증합니다.

삭제 전 애플리케이션 의존 관계와 이전 계획을 확인합니다. 제공자를 삭제하면 애플리케이션 연결이 제거되고 관련 인증 정보에 영향을 주므로 사용자가 해당 인증 절차를 계속 이용하지 못할 수 있습니다. 삭제 후 연결이 자동으로 복원된다고 가정하지 않습니다.

문제 해결

• 제공자를 찾을 수 없음: 이름 검색에서 기존 항목이 누락될 수 있습니다. 검색어를 지우고 목록과 계정 권한을 확인합니다.
• 저장 실패: 이름, 콜백 주소, 서명 키, Scope, 기타 필수 항목과 화면 메시지를 확인합니다. 목록 복귀는 저장 성공의 증거가 아닙니다.
• 로그인 콜백 실패: 애플리케이션이 실제 사용하는 전체 콜백 주소를 제공자 설정, 클라이언트 유형 및 애플리케이션 측 매개변수와 양쪽에서 비교합니다.
• 토큰 또는 사용자 식별자가 예상과 다름: Scope, Subject, 실제 Issuer와 서명 키를 확인하고 애플리케이션 로그로 연동 상태를 조사합니다.
• 변경 후 애플리케이션 로그인 불가: 연결 관계, Client ID, Secret, 서명 키 및 애플리케이션 상태를 확인하고 승인된 복구 계획을 따릅니다.