SAML 신원 제공자 연결과 사용자 특성

SAML 2.0은 신원 제공자(IdP)와 서비스 제공자(SP)가 XML로 인증 및 권한 관련 정보를 교환하는 표준입니다. Foundry는 서비스 제공자로서 Entra ID나 Okta 등의 신원 제공자에서 인증한 사용자의 응답을 받아 세션을 만듭니다. 일반적인 사용 방식은 브라우저 SSO입니다.

양쪽 메타데이터

Foundry의 SAML integration metadata는 신원 제공자에 전달할 서비스 제공자 정보입니다.

Control Panel은 이 정보를 XML로 자동 생성하며 전체 파일을 내려받거나 개별 필드를 복사할 수 있습니다.

반대로 IdP metadata는 신원 제공자의 Entity ID, SSO 및 Single Logout URL과 인증서를 Foundry에 전달하는 정보입니다. 다음 두 방식으로 입력합니다.

• Upload: 신원 제공자에서 받은 XML을 업로드합니다.
• Fetch: metadata discovery URI를 지정해 Foundry가 정보를 가져오게 합니다. 해당 URI에 접근할 네트워크 아웃바운드 정책도 필요합니다.

인증서가 만료되면 로그인이 실패할 수 있습니다. 만료까지 30일 이내인 IdP 인증서가 있으면 Control Panel에 경고가 표시됩니다.

이메일 도메인과 호스트

로그인 화면에서 입력한 이메일 또는 사용자 이름에 따라 보여 줄 신원 제공자를 선택합니다. 각 제공자에 설정한 이메일 패턴과 일치하는 통합만 로그인 선택지로 표시합니다.

@example.com 같은 간단한 입력은 .*@example\.com으로 변환합니다. 모든 사용자에게 선택지를 표시하려면 .*를 사용합니다. 이는 로그인 선택지를 찾는 설정이며 조직의 사용자 허용 정책과 권한 구성도 별도로 필요합니다.

간단한 도메인과 정규식은 기본적으로 대소문자를 구분합니다. 대소문자를 구분하지 않으려면 (?i).*@example\.com 또는 (?i)@example\.com처럼 정규식 앞에 (?i)를 붙입니다. 예시 도메인은 실제 조직 도메인으로 바꿉니다.

Supported hosts는 플랫폼 인스턴스에 등록한 호스트 중에서 선택합니다. 이 호스트를 사용해 ACS와 Single Logout URL을 구성하고, 해당 호스트로 로그인한 사용자에게만 통합을 표시합니다.

사용자 특성 매핑

IdP가 반환하는 SAML assertion에는 이름, 이메일과 추가 claims가 키 및 값 또는 값 목록으로 들어갑니다. 이를 Foundry 사용자 특성에 매핑합니다.

Foundry는 ID로 로그인을 기존 계정에 연결합니다. 바뀔 수 있는 이메일이나 사용자 이름을 ID로 사용하면 이름 변경 때 계정 접근이 끊기거나 새 계정이 생길 수 있습니다.

추가 특성은 Add attribute mapping에서 왼쪽에 Foundry 이름, 오른쪽에 IdP 특성 이름을 입력합니다. 값이 여러 개인 경우 First는 처음 값을, All은 모든 값을 사용합니다.

제공자 그룹

Import user groups from the identity provider를 켜고 Group attribute mapping에 SAML claim의 그룹 키를 입력합니다. IdP에서도 그룹 값을 assertion에 넣도록 설정해야 할 수 있습니다. 사용자가 로그인할 때 각 값에 대응하는 외부 제공자 그룹을 만들고 소속을 반영합니다.

이 옵션을 끄면 로그인 시 제공자 그룹 소속을 갱신하지 않습니다. 이 방식으로 운영한다면 대화형 로그인 없이 소속을 갱신할 SCIM을 사용하는 것이 권장됩니다.

User groups' attribute pattern에는 각 값에서 그룹 이름을 추출할 정규식을 선택적으로 지정합니다. 패턴은 사용할 그룹 이름 전체에 일치해야 합니다.

• 각각의 값이 Engineering, Analysts, Admins라면 패턴을 비워 둡니다.
• 하나의 값이 Engineering,Analysts,Admins라면 [^,]+로 세 그룹 이름을 각각 추출할 수 있습니다.

로그인의 추가 단계

Asynchronous user managers(AUMs)는 로그인 흐름에 추가할 수 있는 설정 가능한 단계입니다. Asynchronous user managers를 펼쳐 선택합니다.

Login Checkpoint를 사용하려면 Checkpoints Login AUM을 먼저 켠 뒤 사유 확인 설정을 만듭니다. 사용자는 로그인 과정에서 구성한 질문을 보고 필요한 사유를 제출합니다.

제공자를 찾지 못하는 오류

Login failed as a suitable authentication provider could not be located. Please contact your administrator for further assistance.는 입력한 사용자 이름이 어떤 허용 이메일 도메인과도 일치하지 않거나 로그인한 호스트가 해당 제공자의 Supported hosts에 없을 때 발생할 수 있습니다.

도메인 패턴의 대소문자와 호스트를 확인한 뒤 통합 테스트로 assertion과 특성 매핑을 확인합니다.

인증서 교체

There are x providers with certificates expiring within 30 days. 경고가 있으면 만료 전에 새 인증서를 준비합니다.

수동 메타데이터 업로드

1. IdP에서 새 인증서를 만들되 기존 인증서도 남기고 활성 상태를 유지합니다.
2. Control Panel에 새 XML을 Upload하고 만료 예정 인증서와 새 인증서가 모두 추출되어 보이는지 확인합니다.
3. 저장한 뒤 IdP가 새 인증서로 서명하도록 전환하고 기존 인증서를 제거합니다.

새 XML을 Foundry에 전달하기 전에 IdP가 새 키로 서명하면 로그인 장애가 발생합니다. 일반적인 인증서 목록 갱신에서는 만료 인증서를 제거한 뒤 다시 업로드할 필요가 없지만, 아래 validUntil 조건은 따로 확인해야 합니다.

자동 메타데이터 갱신

Fetch에서는 Automatically refresh the identity provider's metadata using the provider metadata URI를 선택할 수 있습니다. IdP가 새 인증서로 전환하면 다음 로그인 요청의 초기 검증 실패를 계기로 Foundry가 새 메타데이터를 가져와 요청을 재시도합니다. 이 경로는 사용자의 로그인 중단 없이 갱신하도록 동작합니다.

인증서 교체와 함께 metadata URI도 바뀌면 자동 갱신은 작동하지 않습니다. 기존 인증서가 만료되기 전에 Control Panel의 URI를 수동으로 바꿔야 합니다.

validUntil 만료

일부 IdP 메타데이터의 validUntil은 게시한 인증서 중 가장 늦은 만료가 아니라 현재 활성 서명 인증서의 만료에 연결됩니다. 새 인증서가 XML에 있어도 validUntil을 넘으면 메타데이터 자체가 만료되어 로그인에 실패할 수 있습니다.

IdP가 새 인증서를 사용하면 보통 validUntil도 갱신됩니다. 자동 갱신을 사용하면 전환 후 새 메타데이터를 다시 가져오지만, 자동 갱신이 없다면 IdP의 전환 후 갱신된 XML을 다시 업로드해야 합니다.

실제 제공자별 필드와 화면은 Entra ID, Okta 및 기타 SAML 제공자, 계정 ID를 유지하는 제공자 교체는 SAML 제공자 이전을 참조합니다.