프로젝트 자동 관리

Identity Provider(IdP)가 보내는 속성을 기반으로, 사용자가 SAML 기반 단일 로그인(SSO)으로 로그인하는 순간 올바른 프로젝트 역할과 함께 특정 프로젝트에 자동으로 추가됩니다.

이 가이드는 프로젝트 할당만 다룹니다. 프로젝트 규칙은 팀 할당과 완전히 독립적입니다: 사용자는 어떤 팀 규칙과 일치하든 일치하지 않든 속성 규칙에 의해 특정 프로젝트에 추가될 수 있습니다.

정보

팀 기반 자동 할당은 별도로 문서화되어 있습니다. 동반 가이드는 자동 팀 및 프로젝트 할당을 참고하세요.

이 문서는 Enterprise Knowledge(EK)의 슈퍼 관리자 대시보드에서 이 기능을 구성하는 관리자를 위해 작성되었습니다.

프로젝트 할당이 하는 일

사용자가 SAML SSO로 인증하면 IdP가 SAML 응답에 일련의 속성을 포함합니다 — 예: department, role, memberOf, group, country. EK는 이러한 속성을 구성한 프로젝트 할당 규칙과 비교하여, 일치하면:

• 규칙의 대상 프로젝트 각각에 사용자를 추가합니다(이미 속해 있는 것은 건너뜀).
• 각 프로젝트에 프로젝트 역할을 적용합니다 — 기본 역할, 또는 조건부 재정의가 일치하면 다른 역할.

규칙은 모든 SSO 로그인에서 평가되므로 IdP 속성이 변할 때도 접근이 최신 상태를 유지합니다.

정보

설계상 추가적입니다: 프로젝트 규칙은 언제나 접근을 추가할 뿐입니다. 사용자는 절대 프로젝트에서 제거되지 않으며, 기존 프로젝트 역할은 이전에 일치하던 속성이 일치하지 않게 되어도 절대 강등되지 않습니다. 프로젝트 접근 제거는 여전히 수동/관리자 동작입니다.

정보

팀과 독립적: 프로젝트 규칙은 팀 구성, 홈/결제 팀, 팀 역할에 접근하지 않습니다. 팀 전체 접근이 필요하면 팀 할당 규칙을 대신 사용하거나 함께 사용하세요.

전제 조건

프로젝트 자동 할당을 사용하기 전에:

1. 테넌트에 SAML SSO가 구성되어 있어야 하고 IdP가 일치시킬 속성을 보내야 합니다. SAML 응답에 속성이 없으면 그것을 참조하는 규칙은 일치할 수 없습니다.
2. EK에 대한 슈퍼 관리자 접근이 있어야 합니다. 일부 슈퍼 관리자 역할은 읽기 전용입니다 — 그런 모드에서는 규칙은 보이지만 생성/편집/삭제 컨트롤이 숨겨집니다.
3. 대상 프로젝트가 이미 존재해야 합니다. 규칙은 기존 프로젝트를 참조하며 생성할 수 없습니다.

팁

먼저 속성 이름을 파악하세요. 정확한 속성 이름과 값(예: http://schemas.xmlsoap.org/.../group 대 group)은 IdP가 결정합니다. IdP 관리자 또는 샘플 SAML 어서션으로 확인하세요. 규칙의 속성 이름은 IdP의 속성 이름과 정확히 일치해야 합니다.

구성하는 곳

두 개의 진입점이 있으며 모두 Super Admin 아래에 있습니다:

Automated Management 탭 (모든 프로젝트 규칙)

Super Admin → Projects tab → Automated Management sub-tab.

시스템의 모든 프로젝트 할당 규칙을 나열하며 생성, 편집, 삭제할 수 있게 합니다. 각 규칙은 하나 또는 여러 프로젝트를 대상으로 할 수 있습니다.

프로젝트별 바로가기 (한 프로젝트의 규칙)

Super Admin → Projects tab → Project Management. 프로젝트를 찾고 Actions 열의 방패 아이콘("SAML Project Rules")을 클릭합니다. 그 프로젝트를 대상으로 하는 모든 규칙을 나열하는 모달이 열리며, 여기서 규칙을 추가, 편집, 삭제할 수 있습니다.

• 이 모달에서 현재 프로젝트는 대상으로 잠겨 있어 제거할 수 없습니다.
• 여기서 규칙을 편집하면 다른 대상 프로젝트에도 영향을 줄 수 있습니다. 하나의 규칙이 여러 프로젝트를 한 번에 대상으로 할 수 있기 때문입니다.

프로젝트 규칙의 구조

필드	목적
SAML Attribute Name	검사할 속성(예: department). IdP가 보내는 그대로 정확히 일치시킵니다.
Attribute Value(s)	필요한 값 하나 이상. UI에서는 값을 입력하고 쉼표/Enter를 눌러 각각을 칩/태그로 만듭니다.
IdP packs multi-values into one string	사용자 측 CSV 토글 — 속성 일치 방식 참조.
Wildcard (substring) match	부분 문자열 일치 토글 — 속성 일치 방식 참조.
Default Project Role	재정의가 일치하지 않는 한 모든 대상 프로젝트에 적용되는 역할: Viewer, Editor, Admin.
Target Projects	하나 이상의 프로젝트 (id / 이름 / 팀 / 소유자로 검색 가능). 최소 하나가 필요합니다.
Conditional Role Overrides	추가 속성이 일치할 때 다른 프로젝트 역할을 할당하는 선택적 중첩 규칙 — 조건부 역할 재정의 참조.

속성 일치 방식

이 섹션은 규칙이 기대대로 작동하는지를 결정합니다. 매처의 mental model은 **"하나의 진정으로 모호한 경우를 제외하면 모든 것이 다중 값 집합으로 취급된다"**입니다.

속성 일치는 SAML 접근 통제와 같은 엔진을 사용합니다. 일반 레퍼런스는 해당 가이드의 일치 동작 매트릭스를 참조하세요. 아래 프로젝트 전용 매트릭스는 와일드카드 동작을 포함합니다.

규칙 측 (입력하는 것)

**Attribute Value(s)**에 입력하는 것은 언제나 쉼표로 구분된 토큰 집합으로 취급됩니다. 각 토큰은 필요한 값입니다.

• 단일 값(Finance)의 규칙은 사용자의 속성에 Finance가 포함되어 있으면 일치합니다.
• 다중 값(Finance, US)의 규칙은 사용자의 속성에 그것들이 모두 포함되어 있을 때만 일치합니다 — 부분 집합(⊆) 일치: 규칙의 필요 집합이 사용자의 집합 안에 포함되어야 합니다.

정보

규칙의 쉼표는 언제나 토큰 구분자이므로, 쉼표를 포함하는 문자 그대로의 값(예: Smith, John)과 일치하는 규칙은 작성할 수 없습니다. 실무에서 접근 통제 속성(그룹, 역할, 부서)은 문자 그대로의 쉼표를 거의 포함하지 않으므로 드물게 제한이 됩니다.

일치는 대소문자를 구분하지 않으며 주변 공백은 제거됩니다.

사용자 측 (IdP가 보내는 것)

들어오는 사용자 값의 해석 방식은 그 와이어 형태와 규칙별 토글 하나에 따라 다릅니다:

IdP가 보내는 것	해석 방식	토글 필요?
여러 <AttributeValue> 요소 (네이티브 다중 값)	집합 — 언제나	아니오 — 자동
일반 값(Finance)의 하나의 <AttributeValue>	단일 값	아니오
여러 값을 쉼표로 구분된 문자열 하나에 담은 하나의 <AttributeValue>(Finance,US,Admin)	CSV 토글이 꺼져 있으면 문자 그대로의 단일 값	예 — 아래 참조

토글: "IdP packs multi-values into one string"

일부 IdP는 여러 값을 쉼표로 구분된 문자열 하나로 하나의 속성 값에 담습니다(예: Accounting,Admin,US). 기본적으로 EK는 단일 속성 값을 하나의 문자 그대로 토큰으로 취급하므로, Accounting,Admin,US는 규칙 값 Accounting과 일치하지 않습니다.

• 꺼짐 (기본값): 사용자의 단일 문자열은 하나의 문자 그대로 값입니다. 내장 쉼표는 보존됩니다. 속성이 정말로 단일 값일 때 사용하세요.
• 켜짐: 사용자의 단일 문자열은 일치 전에 쉼표로 분할되어 집합이 됩니다. IdP가 여러 값을 문자열 하나에 담을 때 사용하세요.

이 토글은 사용자의 단일 문자열 값이 해석되는 방식에 만 영향을 줍니다. 규칙 값이 읽히는 방식을 절대 바꾸지 않으며(규칙 쉼표는 언제나 구분자), IdP가 이미 네이티브 다중 값 속성을 보내는 경우 무시됩니다(그것들은 언제나 집합).

동작 매트릭스

사용자의 들어오는 값	토글	규칙 값	일치?
네이티브 ["A","B","C"]	꺼짐	A	✓
네이티브 ["A","B","C"]	꺼짐	A, B	✓
네이티브 ["A","B","C"]	켜짐	A, B	✓
문자열 "A,B,C"	꺼짐	A	✗
문자열 "A,B,C"	꺼짐	A, B	✗
문자열 "A,B,C"	켜짐	A	✓
문자열 "A,B,C"	켜짐	A, B	✓
문자열 "A"	꺼짐	A	✓
문자열 "A"	켜짐	A	✓

토글: "Wildcard (substring) match"

• 꺼짐 (기본값): 각 규칙 토큰은 사용자 토큰과 정확히 일치해야 합니다(대소문자 무시 및 공백 제거 후).
• 켜짐: 각 규칙 토큰은 사용자 토큰 중 하나의 어디에든 나타나면 일치합니다(대소문자 무시 부분 문자열). 예: 규칙 값 val2는 들어오는 값 val1val2val3과 일치합니다. 다중 토큰 규칙에서는 모든 규칙 토큰이 어떤 사용자 토큰에 포함되어야 합니다.

와일드카드는 CSV 토글과 독립적입니다: CSV는 사용자 문자열이 어떻게 토큰으로 분할되는지를 제어하고, 와일드카드는 각 토큰이 어떻게 비교되는지를 제어합니다.

경고

주의: 와일드카드 일치는 더 넓어 의도하지 않은 더 많은 사용자와 일치할 수 있습니다(예: 규칙 admin이 nonadmin과 일치). 특별히 부분 문자열 동작이 필요하지 않는 한 정확 일치를 선호하세요.

조건부 역할 재정의

규칙의 Default Project Role은 규칙에 일치하는 모든 사람에게 적용됩니다. Conditional Role Overrides를 사용하면 추가 속성에 기반하여 일치 사용자 중 일부에게 다른 프로젝트 역할을 부여할 수 있습니다.

각 재정의는 다음을 가집니다:

• 속성 이름과 값
• 프로젝트 역할 (Viewer / Editor / Admin)
• CSV 토글 ("IdP packs multi-values into one string")
• 와일드카드 토글

재정의는 그것을 소유한 규칙 안에서, 그리고 이미 그 규칙의 주 조건에 일치하는 사용자에 대해서만 평가됩니다.

어느 재정의가 적용되는가

하나 이상의 재정의가 일치하면 EK는 가장 구체적인 것을 선택합니다 — 필요한 값 집합이 가장 큰 재정의로 정의됩니다. 두 재정의가 구체성에서 동률이면 가장 먼저 생성된 것이 선택됩니다(경고가 로그됨). 동률 판정에 의존하기보다 모호한 중첩을 제거하도록 재정의를 재구성하세요.

어떤 재정의도 일치하지 않으면 규칙의 Default Project Role이 사용됩니다.

합집합 의미론 및 역할 우선순위

합집합 의미론

프로젝트 규칙은 순수 합집합 의미론을 사용합니다 — "사용자당 하나의 프로젝트" 제약은 없습니다:

• 조건이 일치하는 모든 프로젝트 규칙이 그 대상 프로젝트를 기여합니다.
• 사용자는 일치한 모든 프로젝트의 합집합에 추가됩니다(이미 속해 있는 것은 건너뜀).

역할 우선순위

• 프로젝트 역할 순위: Viewer < Editor < Admin.
• 하나의 규칙 안에서 역할은 가장 구체적인 일치 재정의에서 해석되며, 없으면 규칙의 기본값.
• 서로 다른 역할로 해석되는 여러 일치 규칙이 같은 프로젝트를 대상으로 할 때는 가장 높은 권한의 역할이 이깁니다 — 따라서 사용자는 어떤 일치 규칙에 비해서도 과소 부여되지 않습니다.
• 기존 프로젝트 역할은 절대 강등되지 않습니다. 사용자가 이미 대상 프로젝트의 멤버라면 현재 역할이 유지됩니다.

단계별 구성

프로젝트 할당 규칙 만들기

1. Automated Management 열기

   Super Admin 대시보드를 열고 Projects 탭 → Automated Management 하위 탭으로 이동합니다.

2. 새 규칙 만들기

   New Rule을 클릭합니다.

3. SAML 일치 기준 입력

   SAML Attribute Name(예: memberOf)을 입력하고 **Attribute Value(s)**를 하나 이상 추가합니다 — 값을 입력하고 쉼표/Enter를 눌러 칩을 만듭니다.

4. 토글 설정

   • IdP가 단일 쉼표 구분 문자열로 여러 값을 보내면 IdP packs multi-values into one string을 켜세요.
   • Wildcard (substring) match는 부분 문자열 일치가 필요할 때만 켜세요.

5. 기본 프로젝트 역할 선택

   Default Project Role(Viewer / Editor / Admin)을 선택합니다.

6. 대상 프로젝트 추가

   Target Projects 아래에서 (id / 이름 / 팀 / 소유자로) 검색하고 규칙이 접근을 부여할 각 프로젝트를 추가합니다. 최소 하나가 필요합니다.

7. 조건부 재정의 추가 (선택)

   다른 역할을 받아야 할 부분 집합에 대해 Conditional Role Overrides를 추가합니다.

8. 저장

   Create Rule을 클릭합니다.

규칙 편집 또는 삭제

• Automated Management 목록에서 규칙 행의 편집 및 삭제 아이콘을 사용하거나 프로젝트별 방패 아이콘 모달을 엽니다.
• 규칙을 삭제하면 대상 목록과 역할 재정의가 제거되지만, 사용자가 이미 가진 프로젝트 구성은 변경하지 않습니다.

단일 프로젝트의 규칙 관리

1. Project Management 열기

   Projects → Project Management에서 프로젝트를 찾습니다.

2. SAML Project Rules 열기

   Actions 열의 방패 아이콘("SAML Project Rules")을 클릭합니다.

3. 규칙 관리

   이 프로젝트를 대상으로 하는 규칙을 추가 / 편집 / 삭제합니다. 현재 프로젝트는 대상으로 잠긴 채 유지됩니다.

실제 예제

예제 1 — 그룹을 편집자로 프로젝트에 매핑

목표: memberOf에 KB-Editors가 포함된 사용자에게 "Knowledge Base" 프로젝트의 편집자 접근을 부여합니다.

• 속성 memberOf = KB-Editors
• Default Project Role Editor
• Target Projects: Knowledge Base

예제 2 — IdP가 단일 패킹 그룹 문자열을 보냄

목표: 위와 같지만 IdP가 memberOf를 KB-Editors,All-Staff,VPN-Users와 같은 하나의 문자열로 보냅니다.

• 속성 memberOf = KB-Editors
• IdP packs multi-values into one string = On
• Default Project Role Editor
• Target Projects: Knowledge Base

CSV 토글이 켜져 있으므로 패킹된 문자열이 분할되어 KB-Editors가 토큰 중 하나로 일치합니다.

예제 3 — 두 속성을 함께 요구

목표: US와 Engineering 모두에 속한 사용자만 "US Engineering Docs" 프로젝트에 접근합니다.

• 속성 groups = US, Engineering (두 개의 칩)
• Target Projects: US Engineering Docs

이 규칙은 사용자의 groups 집합이 두 값을 모두 포함할 때만 일치합니다.

예제 4 — 기본 역할에 재정의로 상향

목표: department=Support의 모든 사용자는 "Support Runbooks" 프로젝트의 Viewer 접근을 얻고, 팀 리드는 Editor를 얻습니다.

• 속성 department = Support, Default Project Role Viewer
• 재정의: 속성 title = Lead → Editor

department=Support, title=Lead 사용자는 Editor를, 일반적인 department=Support 사용자는 Viewer를 얻습니다.

예제 5 — 두 규칙에서 같은 프로젝트

• 규칙 A: role=analyst → 프로젝트 X를 Viewer로.
• 규칙 B: role=lead → 프로젝트 X를 Editor로.

둘 다에 일치하는 사용자는 프로젝트 X에서 Editor가 됩니다(가장 높은 권한이 이김).

동작, 엣지 케이스, 중요한 참고 사항

• 추가만 합니다. 규칙은 사용자를 프로젝트에서 제거하지 않으며 기존 역할을 절대 강등하지 않습니다. 프로비저닝 해제는 별개의 수동 동작입니다.
• 팀과 독립적. 프로젝트 규칙은 팀 구성, 팀 역할, 사용자의 홈/결제 팀에 영향을 주지 않습니다.
• 모든 로그인에서 평가됩니다. 사용자의 IdP 속성 변경은 다음 SSO 로그인 때 적용됩니다. 새 규칙을 만들어도 현재 로그인하지 않는 사용자에게 소급 적용되지 않습니다.
• 백그라운드에서 적용됩니다. 로그인 후 프로젝트 추가는 비동기 작업으로 처리되므로 매우 큰 대상 집합은 완전히 적용되기까지 잠시 걸릴 수 있습니다.
• 이미 멤버인 프로젝트는 건너뜁니다. 사용자는 이미 속해 있지 않은 프로젝트에만 추가되며, 기존 역할은 유지됩니다.
• 없는 역할은 건너뜁니다. 해석된 역할이 특정 프로젝트에 존재하지 않으면, 전체 로그인을 실패시키는 대신 그 프로젝트를 건너뜁니다.
• 삭제된 대상 프로젝트는 안전하게 무시됩니다(로그 기록).
• 빈 규칙 값은 거부됩니다. 공백 제거와 빈 쉼표 슬롯 제거 후 아무것도 남지 않는 값은 아무것도와 일치하지 않으므로 수락되지 않습니다.
• 값은 저장을 위해 정규화됩니다. 각 값 주위의 공백은 제거되고 빈 슬롯은 삭제됩니다. 표시용으로 원래 대소문자가 유지되지만 일치는 대소문자를 무시합니다.
• 감사. 프로젝트 규칙과 그 역할 재정의의 생성, 업데이트, 삭제는 슈퍼 관리자 감사 로그에 기록됩니다.

문제 해결

규칙은 맞아 보이는데 사용자가 추가되지 않음

• 속성 이름이 IdP가 보내는 것과 정확히 일치하는지 확인하세요(이름은 흔히 완전한 URI입니다).
• 값의 대소문자/철자를 확인하세요 — 일치는 대소문자를 무시하지만 그 외에는 토큰과 일치해야 합니다.
• IdP가 하나의 쉼표 구분 문자열로 여러 값을 보내면 **"IdP packs multi-values into one string"**을 켜세요.
• 일치가 부분 집합임을 기억하세요 — 다중 값 규칙은 사용자가 나열된 모든 값을 가지기를 요구합니다.
• 규칙에 최소 하나의 대상 프로젝트가 있는지 확인하세요.
• 규칙이 적용되려면 사용자가 규칙 생성 후 다시 로그인해야 합니다.

사용자는 일치했지만 잘못된 역할을 받음

• 조건부 재정의를 확인하세요 — 더 구체적인 재정의가 적용되고 있을 수 있습니다.
• 규칙 간에는 가장 높은 권한이 이기고, 기존 역할은 절대 강등되지 않음을 기억하세요.

부분 문자열 일치가 너무 많은 사용자를 잡아듦

• Wildcard를 끄고 정확 일치를 사용하거나 값을 더 구체적으로 만드세요.

규칙 편집이 예상하지 못한 프로젝트의 접근을 변경함

• 규칙은 여러 프로젝트를 대상으로 할 수 있습니다. 편집하면(프로젝트별 방패 아이콘 모달에서 포함) 모든 대상 프로젝트에 영향을 줍니다.

빠른 레퍼런스

개념	동작
범위	프로젝트만 — 팀이나 홈 팀은 절대 건드리지 않음.
규칙 값의 쉼표	언제나 토큰 구분자 (부분 집합 일치).
네이티브 다중 값 SAML	언제나 집합으로 일치.
단일 패킹 문자열	CSV 토글이 켜져 있을 때만 집합으로 분할.
와일드카드 토글	정확 대신 부분 문자열 일치.
일치 방향	규칙의 필요 집합 ⊆ 사용자의 집합.
구체성	더 큰 필요 집합 = 더 구체적 (재정의에 사용).
프로젝트 역할	Viewer < Editor < Admin.
평가	합집합 — 일치하는 모든 규칙이 그 프로젝트를 기여.
같은 프로젝트, 여러 역할	가장 높은 권한이 이김.
기존 구성/역할	절대 강등 또는 제거되지 않음.
평가 주기	모든 SSO 로그인.
대상 프로젝트	규칙당 최소 하나 필요.
위치 (모든 규칙)	Super Admin → Projects → Automated Management.
위치 (하나의 프로젝트)	Super Admin → Projects → Project Management → 방패 아이콘.