SAML 인증 및 접근 제어

조직의 액세스 정책을 정의하고 SAML을 관리하기 위한 지침 및 방법론입니다.

SAML을 통해 조직은 기존 ID 제공자(IdP)를 사용하여 Tulip 사용자의 인증 및 접근 권한을 관리할 수 있습니다. 이 가이드에서는 SAML 프로토콜을 통한 엔터프라이즈급 IdP 통합 구현에 사용할 수 있는 옵션을 자세히 설명합니다.

사전 준비

• Tulip 사용자 역할 이해
• 예상되는 Tulip 사용자를 역할별로 분류하여, SAML 속성을 해당 사용자의 Tulip 역할로 업데이트할 준비를 하십시오.
• 조직 내에서 IdP 및 Tulip 계정을 구성할 담당자를 지정하십시오.

IdP 구성

Tulip 인스턴스가 로그인에 SAML을 사용하도록 구성되면, Tulip은 Tulip 내의 사용자와 기업 ID 공급자(IdP) 내의 사용자 간의 연결을 유지합니다. IdP에 계정을 보유한 특정 사용자는 주어진 Tulip 인스턴스에 최대 하나의 계정만 가질 수 있습니다. Tulip은 “NameID”라고 하는 SAML 고유의 개념을 사용하여 이러한 연결을 유지합니다. NameID는 SAML 인증이 제공하는 불투명한 유형의 식별자이며, IdP에 의해 정의됩니다.

NameID는 이러한 연결을 유지하는 데 사용되므로, Tulip은 NameID가 안정적일 것으로 기대합니다. 즉, 특정 IdP 사용자에 대해 Tulip이 수신하는 NameID는 해당 사용자의 사용 기간 동안 변경되어서는 안 됩니다. 사용자의 NameID가 변경될 경우 연결이 끊어지며, 로그인 시 오류가 발생할 수 있습니다.

Tulip은 시간이 지나도 변경되지 않는 NameID를 제공하도록 IdP를 구성할 것을 강력히 권장합니다. 이러한 이유로 Tulip은 시간이 지남에 따라 변경될 수 있는 이름이나 이메일 주소를 NameID로 사용하는 것을 권장하지 않습니다. 절대 변경되지 않는 내부 객체 ID나 계정 이름을 사용하도록 IdP를 구성할 것을 권장합니다.

NameID는 사람이 읽거나 알아볼 수 있을 필요가 없습니다(사실, 보안상 NameID로 알아볼 수 없는 값을 사용하는 것이 일반적으로 더 좋습니다).

IdP를 구성할 때 NameID 형식을 ‘Persistent’로 설정하는 것을 권장합니다. 이는 Tulip에 해당 값이 사용자의 수명 주기 동안 변하지 않아야 함을 나타냅니다.

NameID 속성의 소스 값을 매핑할 때는 "객체 ID"나 "사용자 주체 이름"과 같이 변경되지 않는 것으로 알려진 값에 매핑하십시오.

Microsoft Entra

Microsoft Entra를 IdP로 사용하는 고객은 다음의 구체적인 지침에 따라 Tulip 애플리케이션이 영구적인 NameID를 사용하도록 구성하십시오:

1. Entra에서 Tulip 인스턴스와 연결된 엔터프라이즈 애플리케이션부터 시작하십시오.
2. 왼쪽 탐색 메뉴에서 "관리" 그룹 아래의 "단일 로그인"을 클릭합니다.
3. “속성 및 클레임(Attributes & Claims)” 섹션을 편집합니다.
4. "필수 클레임" 섹션에서 "고유 사용자 식별자(Name ID)"라는 클레임의 행을 클릭합니다.
5. "이름 식별자 형식"이 "영구(Persistent)"로 설정되어 있는지 확인하십시오. "소스"를 "속성"으로 설정하고, 사용자의 전체 수명 주기 동안 안정적으로 유지될 속성을 선택하십시오. user.userprincipalname 및 user.objectid가 좋은 선택입니다.

SAML 및 Tulip 구성 옵션

제어 모드

Tulip 제어 모드는 사용자가 Tulip에 처음 로그인할 때만 SAML 속성 매핑에서 사용자의 Tulip 역할과 작업 공간을 가져온다는 것을 의미합니다 .

Tulip에서 비활성화된 사용자는 로그인할 수 없습니다.

IdP 제어 모드는 사용자가 로그인할 때마다 IdP에서 사용자의 Tulip 역할과 작업 공간이 업데이트됨을 의미합니다 .

기본 역할 매핑(Tulip 제어 모드만 해당)

첫 로그인 시, 모든 사용자에게 기본 액세스 수준(플레이어 액세스 권한이 있는 뷰어)이 부여됩니다. 이후 계정 소유자는 Tulip 내에서 수동으로 역할을 적절한 수준으로 조정해야 합니다.

작업 공간

워크스페이스에 대해 자세히 알아보기

역할 속성과 마찬가지로, 이제 사용자를 처음 생성할 때 특정 워크스페이스에 자동으로 매핑하는 옵션이 제공됩니다. 사용자 생성 후, 계정 소유자는 워크스페이스 간에 사용자를 유연하게 이동시킬 수 있습니다.

SAML 사용자 정의 워크스페이스 매핑

:::(정보) (다중 워크스페이스) Tulip 제어 모드에서만 사용자를 여러 워크스페이스에 매핑할 수 있다는 점에 유의하십시오.

IdP 제어 모드에서는 각 사용자가 단일 워크스페이스의 구성원일 수만 있습니다.
:::

첫 로그인 시, 사용자에게는 워크스페이스 속성에 명시된 그룹을 기반으로 워크스페이스 액세스 권한이 할당됩니다. 그 이후부터는 Tulip이 해당 사용자의 워크스페이스 속성을 더 이상 읽지 않으며, 워크스페이스 변경은 계정 소유자가 플랫폼에서 직접 수행해야 합니다.

기본 작업 공간 매핑

첫 로그인 시, 모든 사용자에게 귀하가 선택한 기본 작업 공간에 대한 접근 권한이 부여됩니다. 이후 계정 소유자는 작업 공간 접근 권한을 조정할 수 있습니다.

사용자 그룹

모든 SAML 구성에서 사용자를 Tulip의 사용자 그룹{target=_blank} 기능에 매핑할 수 있습니다.

사용자 그룹은 계정 수준에서 존재합니다. 사용자가 사용자 그룹에 매핑되면 모든 워크스페이스에서 해당 사용자 그룹의 구성원이 됩니다.

'사용자 그룹' 옵션을 '켜기'로 설정하면, SAML의 속성 값을 기반으로 IdP의 사용자를 Tulip의 사용자 그룹에 매핑할 수 있습니다.

그 후, 최대 100개의 SAML 속성을 지정하고 각 속성의 값을 사용자 그룹에 매핑할 수 있습니다. 사용자는 여러 사용자 그룹에 매핑될 수 있습니다.

사용자 그룹 매핑 및 제어 모드 동작

사용자 그룹 멤버십 동작은 제어 모드 설정에 따라 달라집니다.

• Tulip 제어 모드: 사용자의 SAML 매핑 그룹은 첫 로그인 시에만 적용됩니다. 그 이후에는 Tulip 내에서 그룹 멤버십을 관리할 수 있으며, 수동으로 변경한 내용은 이후 로그인 시에도 유지됩니다.
• IdP 제어 모드: 사용자의 전체 그룹 멤버십은 로그인할 때마다 현재 SAML 속성을 기준으로 재계산됩니다. Tulip은 매핑을 통해 산출된 그룹을 할당하고, Tulip 내에서 수동으로 할당된 그룹을 포함하여 매핑에 포함되지 않은 그룹에서는 사용자를 제거합니다.

인증 옵션

사용자 인증에 FIDO 키를 사용하려면 “인증 방법 일치 비활성화”를 설정해야 합니다.

인증 컨텍스트 클래스

인증 컨텍스트 클래스는 사용자가 인증하는 데 사용되는 지정된 방법입니다.

이 기능이 활성화되면 사용자는 지정된 방법만을 사용하여 인증할 수 있습니다.

비활성화된 경우, 인증 방법 선택은 전적으로 ID 제공자에게 위임됩니다.

인증 강제

Tulip은 SAML forceAuthn 매개변수를 사용하여 사용자가 로그인할 때마다 IdP를 통해 재인증해야 하는지, 아니면 기존 OS 수준의 SAML 세션을 재사용할 수 있는지를 제어합니다. Tulip은 isPassive 매개변수를 사용하지 않습니다. 여기서 기존 세션이란 Tulip 고유의 세션이 아닌 OS 수준의 SAML 세션(예: ID 제공자와 연결된 Windows 세션)을 의미합니다.

강제 인증 켜기(기본값): Tulip은 forceAuthn=true를 전송하여, 기존 OS 수준 SAML 세션의 유무와 관계없이 사용자가 로그인할 때마다 IdP를 통해 능동적으로 인증하도록 요구합니다. 이 설정은 사용자가 재인증을 우회할 수 없도록 보장합니다.

강제 인증 끄기: Tulip은 forceAuthn=false를 전송합니다. 사용자가 이미 IdP에서 인식하는 활성 OS 수준 SAML 세션을 보유하고 있는 경우, 자격 증명을 다시 입력하지 않고도 Tulip에 자동으로 로그인됩니다.

사용자 지정

사용자 로그인을 위한 선택적 사용자 정의.

로그인 버튼 레이블 - Tulip 로그인 페이지의 SAML 로그인 버튼에 표시될 텍스트를 사용자 지정합니다.

사용자 지정 지원 이메일 - 사용자가 SAML 로그인 오류가 발생했을 때 표시될 사용자 지정 이메일 주소를 설정합니다. 이를 통해 사용자를 내부 IT 지원팀으로 안내할 수 있습니다. 비워두면 기본 지원 이메일 주소인 "support@tulip.co"이 사용됩니다.

데스크톱 플레이어: 인증을 위한 OS 기본 브라우저

SSO 로그인 또는 OAuth 커넥터 인증에 기본 브라우저를 통해서만 가능한 통합이 필요한 경우, Tulip 플레이어를 구성하여 내장된 창 대신 OS 기본 브라우저에서 인증 흐름을 열도록 설정할 수 있습니다.

버전 요구 사항

OS 기본 브라우저 인증을 사용하려면 다음 Tulip 버전 요구 사항을 충족해야 합니다:* 데스크톱 플레이어 2.8 이상* 팩토리 릴리스 318 이상

기능 동작

이 동작은 SSO를 통한 데스크톱 플레이어 로그인 및 Tulip 앱 내 OAuth 커넥터 인증 모두에 적용됩니다. 두 경우 모두 사용자가 인증을 시작하면 기본 시스템 브라우저가 열려 다음 절차를 처리합니다:

1. 시스템 브라우저가 실행되어 조직의 IDP(Identity Provider) 로그인 페이지로 이동합니다.
2. 사용자는 웹에서와 똑같이 브라우저에서 로그인 절차(인증 정보 입력, MFA 완료 등)를 완료합니다.
3. 인증이 완료되면 브라우저 페이지에 다음 메시지가 표시됩니다."완료되었습니다! 이 창을 닫으셔도 됩니다."
4. 브라우저 창은 계속 열려 있습니다. 자동으로 닫히지 않으므로 사용자가 수동으로 닫아야 합니다.
5. Tulip Desktop Player는 로그인이 완료된 것을 감지하고 정상적으로 진행합니다.

예상되는 권한 요청

사용자의 OS 및 브라우저 설정에 따라 하나 또는 두 개의 권한 요청 창이 표시될 수 있습니다:

1. Desktop Player 방화벽/로컬 서버 권한 (OS 수준)

인증이 시작되면 데스크톱 플레이어는 인증 응답을 수신하기 위해 임시 로컬 서버를 생성합니다. OS 및 보안 설정에 따라, 데스크톱 플레이어가 수신 연결을 허용할 수 있는지 묻는 시스템 방화벽 또는 네트워크 액세스 확인 창이 나타날 수 있습니다.

• 필요한 조치: 연결을 허용하십시오. 이는 정상적인 동작이며, 로그인을 완료하기 위해 필수적입니다.
• OS 설정에 따라 이 알림은 처음 한 번만 표시되거나 매번 표시될 수 있습니다.

2. 브라우저 로컬 네트워크 액세스 권한(브라우저 수준)

사용자가 ID 제공자를 통해 로그인을 완료하면, 브라우저의 인증 완료 페이지는 앞서 설명한 로컬 서버에 요청을 보내 결과를 데스크톱 플레이어로 전송합니다. 일부 브라우저는 해당 페이지가 로컬 네트워크의 기기에 액세스할 수 있도록 허용할지 묻는 권한 확인 메시지를 표시합니다.

• 필요한 조치: 액세스를 허용하십시오. 이는 인증 흐름에서 예상되는 안전한 단계입니다.
• 요청은 localhost로만 전송되며, 암호화된 인증 응답만 포함됩니다. 이 단계에서는 민감한 인증 정보가 전송되지 않습니다.

사용자 관점에서 볼 때의 차이점 요약

아래 표는 기본 인증과 OS 브라우저 기반 인증의 동작을 비교한 것입니다:

예시: IdP 내에서 액세스 그룹 생성

다음 예시를 통해 SAML 설정의 다양한 옵션을 함께 사용하는 방법을 확인할 수 있습니다.

표준화된 Tulip 역할 생성

모든 사용자는 IdP에서 지정한 역할 속성이 있어야 하며, 이를 통해 Tulip은 사용자가 IdP 사용자 이름과 비밀번호로 인증한 후 해당 사용자의 권한을 결정할 수 있습니다.

또한 이 ‘역할’ 필드를 사용하여 표준 명명 규칙에 따라 사용자가 액세스할 수 있는 사이트를 결정할 수도 있습니다. 역할 필드는 단순히 설정된 변수일 수 있지만, IdP 내에서 사용자를 Tulip 전용 그룹에 할당하고 이를 속성에 매핑하는 것이 권장됩니다.

역할

모든 사용자에게는 하나의 워크스페이스 내에서 하나의 역할이 할당됩니다.

Tulip이 사용자에 대해 여러 개의 유효한 역할을 수신하면 다음과 같은 논리를 적용합니다.

설정된 역할에 내장 역할(Operator, Builder 등)이 포함된 경우, Tulip은 정적인 내부 계층 구조에 따라 가장 높은 순위의 내장 역할을 선택합니다. 사용자 정의 역할은 항상 모든 내장 역할보다 순위가 낮으므로, 내장 역할이 하나라도 존재하면 사용자 정의 역할은 절대 선택되지 않습니다.

해당 집합에 사용자 정의 역할만 포함된 경우, Tulip은 SAML 페이로드에서 수신된 첫 번째 사용자 정의 역할을 선택합니다.

Tulip 사용자 역할에 대해 자세히 알아보세요.

사이트

조직에 두 개의 사이트가 있고, 각 사이트마다 Tulip Instance 이 있다고 가정해 봅시다.

각 사이트를 위치(각각 텍사스와 런던)로 표시할 수 있습니다.

사이트와 역할 결합

이 두 속성을 결합하여 사용자에게 할당할 그룹 매트릭스를 만들 수 있습니다. 필터링하기 쉽도록 조직에서는 값의 앞이나 뒤에 'Tulip'을 추가하는 것이 좋습니다.

표기 규칙: tulip-siteRole

제인 스미스가 텍사스 사이트의 사이트 책임자라면, 그녀를 tulip-texasAccountOwner 그룹에 할당해야 합니다. 제인 스미스가 런던 사이트에 대한 조회 권한도 필요한 경우, 그녀를 tulip-londonViewer 그룹에 추가할 수 있습니다.

이러한 그룹을 Tulip의 속성으로 노출

IdP에서 제인에게는 ‘tulip-role’이라는 속성이 있어야 하며, 이 속성에는 그녀가 속한 그룹 중 접두사 “tulip-”을 포함하는 모든 그룹이 매핑됩니다.

제인이 Tulip에 로그인하면 ‘tulip-role’ 속성에는 ‘tulip-texasAccountOwner’와 ‘tulip-londonViewer’라는 두 가지 값이 부여됩니다 . 각 Tulip instance 에 대한 역할 매핑을 개별적으로 구성하여, 제인이 각 인스턴스에서 올바른 권한을 부여받을 수 있도록 할 수 있습니다.

전역 역할

예를 들어 “Viewer” 역할과 같은 전역 액세스 역할을 생성할 수도 있습니다. 이러한 사용자는 동일한 권한으로 모든 Tulip instance 에 로그인할 수 있습니다. 이를 위한 권장 형식은 다음과 같습니다:

tulip-globalViewer

이 사용자가 각 인스턴스에 액세스할 수 있도록 하려면, ‘계정 설정’의 SAML 구성 페이지에서 각 개별 인스턴스에 대해 이 역할 매핑을 설정해야 합니다.

{{snippet.원하는 정보를 찾으셨나요?}}