OIDC 신원 제공자로 Foundry 로그인 구성하기
OpenID Connect 1.0(OIDC)은 OAuth 2.0 위에서 사용자 신원과 기본 프로필을 전달하는 인증 계층입니다. 이 구성에서는 Foundry가 신원 제공자의 클라이언트가 됩니다. 외부 앱이 Foundry API를 사용하도록 등록하는 OAuth 클라이언트와 방향이 다릅니다.
공개 OIDC 제공자는 누구나 계정을 만들 수 있는 경우가 있습니다. 이런 제공자를 잘못 구성하면 원하지 않는 사용자가 플랫폼 인스턴스에 접근할 수 있으므로 허용 사용자, 조직 배정과 접근 조건을 먼저 정해야 합니다.
네트워크와 등록 URL
OIDC 인증과 메타데이터 조회에는 Foundry의 아웃바운드 호출이 필요합니다. 사용할 egress 정책을 선택하거나 해당 제공자 엔드포인트에 접근할 네트워크 정책을 만듭니다.
Foundry가 제공하는 Redirect URL을 IdP의 클라이언트에 등록합니다. 사용자가 승인 및 인증을 마치면 제공자가 결과를 이 주소로 돌려보내고 Foundry가 응답을 처리합니다.
로그아웃에는 Foundry의 front-channel URL과 back-channel URL을 사용할 수 있습니다. 브라우저를 경유하는 방식과 서버 간 전달 방식 중 원하는 로그아웃 동작에 따라 IdP가 지원하는 URL을 등록합니다.
제공자 메타데이터
Metadata discovery URI를 지정하면 필요한 정보를 자동으로 가져올 수 있습니다. 수동 구성에는 다음 항목을 사용합니다.
| 항목 | 용도 |
|---|---|
Issuer | 제공자를 식별하는 URL입니다. Discovery 정보에서 엔드포인트, claims, 지원 scope와 공개키 등을 확인합니다. |
Authorization endpoint | 사용자를 이동시켜 authorization code를 받는 제공자 주소입니다. |
Token endpoint | Authorization code를 access token 및 ID token으로 교환하는 주소입니다. |
JWKS URI | ID token 서명을 검증할 공개키 집합의 주소입니다. |
User info endpoint | 제공자에 따라 지원 여부가 다르며, 지원하는 제공자 중 일부에서는 필요합니다. 사용자 프로필을 조회합니다. |
End session endpoint | 제공자 세션에서 로그아웃하는 선택 항목입니다. 제공자가 지원하지 않을 수도 있습니다. |
클라이언트 인증과 scope
IdP에서 Foundry용 client ID와 client secret을 발급받습니다. 발급 절차는 제공자마다 다릅니다. Foundry가 token endpoint에 인증할 방식으로 HTTP Basic 또는 폼 본문에 자격 정보를 넣는 POST 방식을 선택합니다.
Scope는 ID token과 UserInfo 응답에 포함할 claims의 범위를 정합니다. Foundry 통합에는 openid, email, profile을 모두 포함해야 합니다.
이메일 선택 조건과 호스트
사용자가 로그인 화면에 입력한 이메일 또는 사용자 이름과 일치하는 패턴을 가진 제공자만 선택지로 표시합니다. @example.com은 .*@example\.com으로 변환하며, 모든 사용자에게 보이게 하려면 .*를 사용할 수 있습니다.
기본적으로 대소문자를 구분합니다. 대소문자를 구분하지 않으려면 (?i).*@example\.com 또는 (?i)@example\.com처럼 (?i)를 앞에 붙입니다. 이는 제공자 선택 조건이며 사용자 접근을 허가하는 전체 정책을 대신하지 않습니다.
Supported hosts에는 플랫폼 인스턴스에 등록한 호스트를 선택합니다. 해당 호스트로 로그인한 사용자에게만 이 제공자를 표시합니다.
사용자 특성과 계정 ID
Claims는 이름, 이메일 등 사용자 정보를 키와 값 또는 값 목록으로 전달합니다. Foundry 특성을 실제 제공자 claim에 매핑합니다.
| Foundry 특성 | 기본 claim 및 조건 |
|---|---|
ID | 기본값은 sub입니다. 비어 있지 않고 모든 응답에 있어야 하며, 대소문자와 형식이 일관되고 계정 수명 동안 바뀌지 않아야 합니다. 한 사용자를 영구적으로 고유 식별합니다. |
Username | preferred_username입니다. 다른 사람이 읽기 쉬운 특성으로 바꿀 수 있습니다. |
Email | email입니다. |
First name | given_name입니다. |
Last name | family_name입니다. |
이메일이나 사용자 이름처럼 바뀔 수 있는 값은 ID로 피합니다. Foundry는 ID로 기존 계정을 찾으므로 변경 시 계정 접근이 깨질 수 있습니다.
Microsoft Entra ID의 OIDC 통합에서는 ID를 sub 대신 oid로 지정합니다. Entra의 SCIM 요청에는 sub가 전달되지 않으므로 로그인과 프로비저닝을 같은 식별자로 연결해야 합니다.
추가 특성은 Add attribute mapping에서 왼쪽에 Foundry 이름, 오른쪽에 JWT claim 경로를 지정합니다. JSONPath를 사용할 수 있습니다. 기본적으로 claim을 단일 문자열로 추출하며, 배열 원소를 각각 추출하려면 [*]를 붙입니다. 예를 들어 groups가 "[group1, group2]"라는 한 문자열로 추출되는 경우 groups[*]는 ["group1", "group2"]처럼 개별 값으로 추출합니다.
여러 값의 매핑 방식은 First 또는 All을 선택합니다. First는 첫 값, All은 전체 값을 Foundry 특성으로 사용합니다.
제공자 그룹 동기화
Import user groups from the identity provider를 켜고 그룹 claim의 경로를 입력합니다. 로그인 시 각 값을 외부 제공자 그룹으로 반영하고 사용자를 구성원으로 등록합니다.
옵션을 끄면 로그인 때 그룹 소속을 갱신하지 않습니다. 이 경우 대화형 로그인 없이 그룹 소속을 갱신하는 SCIM을 함께 구성하는 방식이 권장됩니다.
Prompt와 로그인 추가 단계
Prompts는 인증 중 사용자에게 어떤 상호작용을 요구할지 정하는 선택 설정입니다.
| 값 | 동작 |
|---|---|
none | 인증이나 동의 화면을 표시하지 않습니다. 기존 인증 및 동의 등 필요한 조건이 없으면 login_required나 interaction_required 같은 오류가 발생할 수 있습니다. |
login | 사용자에게 다시 인증하도록 요청합니다. |
consent | 정보 제공 동의를 요청합니다. |
select_account | 같은 제공자의 여러 계정 중 사용할 계정을 선택하게 합니다. |
여러 prompt를 함께 선택할 수 있지만 none은 다른 값과 결합하면 안 됩니다. 아무 prompt도 선택하지 않은 경우의 기본 동작은 제공자에 따릅니다. 빈 선택과 none은 같은 의미가 아닙니다.
Asynchronous user managers는 로그인 흐름에 추가하는 단계입니다. Login Checkpoint가 필요하면 Checkpoints Login AUM을 켜고 사유 확인 설정을 만듭니다.
저장 후에는 통합 테스트와 호스트 설정에서 로그인 결과와 특성 매핑을 확인합니다. MFA와 사용자 조직 및 그룹 배정도 로그인 정책에 맞게 구성해야 합니다.