내부 애플리케이션용 SSO: SAML/OIDC 클레임을 역할과 팀에 매핑하기

클레임 매핑이 내부 앱에서 중요한 이유

싱글 사인온은 간단해 보입니다. "Okta로 로그인"이나 "Azure AD로 로그인"을 클릭하면 끝나는 것 같지만, 실제 어려운 부분은 그다음에 어떤 일이 벌어지는가입니다. 명확한 클레임 매핑이 없으면 현업 담당자가 급여를 보거나 반대로 신입이 첫날에 필요한 도구를 열 수 없게 되는 등 권한이 너무 넓거나 너무 좁아집니다.

내부 앱은 공개 앱보다 더 까다롭습니다. 여러 팀이 같은 도구를 공유하고, 조직도가 자주 바뀝니다. 하나의 도구를 Support, Finance, Sales가 동시에 쓸 수 있습니다. 조직 개편, 계약직의 출입, 팀명 변경 등이 계속 발생합니다. 접근 규칙이 사람들 머릿속에만 있으면 SSO는 그 혼란을 그대로 앱에 복사해 넣습니다.

클레임 매핑은 IdP(Identity Provider)가 보내는 정체성 데이터를 그룹, 부서, 직책 등에서 앱이 이해하는 권한으로 바꾸는 방법입니다. 보통 다음을 결정하는 것을 포함합니다:

• 앱에 어떤 역할이 있는가(admin, manager, viewer 등)
• 사용자가 어떤 팀이나 워크스페이스에 속하는가
• 각 역할이 무엇을 할 수 있고, 각 팀이 무엇을 볼 수 있는가
• 누가 자동으로 접근을 얻고, 누가 승인이 필요한가

주된 문제는 보통 두 가지에서 옵니다:

• 잘못된 매핑: 그룹 이름이 잘못된 역할에 매칭되거나, "All Employees"처럼 넓은 그룹이 실수로 관리자 권한을 주는 경우
• 누락된 클레임: IdP가 일부 사용자에게 그룹을 보내지 않거나 속성이 비어 있거나 토큰이 너무 커서 잘리는 경우

앱은 안전한 기본값을 가져야 하며, 누락되거나 예기치 않은 데이터가 우발적 접근으로 이어지지 않도록 해야 합니다.

SAML과 OIDC 클레임을 쉽게 이해하기

SSO로 로그인하면 IdP는 앱에 사용자에 대한 작은 사실 묶음을 보냅니다. 각 사실은 클레임으로, 예를 들어 "email = [email protected]"이나 "department = Finance" 같은 라벨이 붙은 필드입니다.

SAML과 OIDC는 비슷한 정보를 전달할 수 있지만 포장 방식이 다릅니다.

SAML은 오래된 엔터프라이즈 환경에서 흔합니다. 보통 XML 문서(어설션)를 보내고 그 안의 attributes가 앱이 읽는 클레임입니다.

OIDC는 OAuth 2.0 위에 구축된 최신 방식입니다. 보통 서명된 JSON 토큰(ID 토큰)과 선택적 사용자 정보를 보내며, 토큰 내부 필드가 클레임입니다.

내부 앱에서는 보통 다음 소수의 클레임만 신경 씁니다:

• 이메일 주소
• IdP의 안정적인 사용자 ID(주체, subject)
• 전체 이름(또는 이름/성)
• 그룹 멤버십(팀, 보안 그룹)
• 부서나 직책

한 가지 구분은 많은 혼란을 막아줍니다:

인증(Authentication)은 "이 사용자는 누구인가?"에 답합니다. 안정적인 사용자 ID와 이메일 같은 클레임은 SSO 로그인과 앱 계정을 연결하는 데 도움을 줍니다.

인가(Authorization)는 "무엇을 할 수 있는가?"에 답합니다. 그룹이나 부서 같은 클레임은 사용자를 앱 내부의 역할과 팀에 매핑하는 데 사용됩니다.

두 사람이 인증을 성공하더라도, "Finance" 그룹 클레임이 있는 사람만 결제 화면에 접근해야 합니다.

역할과 팀: 무엇에 매핑할지 결정하기

SAML 속성을 매핑하거나 OIDC 클레임을 권한으로 변환하기 전에 앱이 알아야 할 두 가지를 명확히 하세요:

• 역할(Role)은 사용자가 무엇을 할 수 있는지를 정의합니다(권한).
• 팀(Team)은 사용자가 어디에 속하는지를 정의합니다(범위).

역할은 이 사람이 볼 수 있는지, 편집할 수 있는지, 승인/내보내기/사용자 관리/설정 변경을 할 수 있는지를 결정합니다.

팀은 이 사람이 어느 부서, 지역, 큐 또는 비용 센터에서 일하는지와 어떤 레코드를 봐야 하는지에 대한 질문에 답합니다.

역할은 작고 안정적으로 유지하세요. 대부분의 내부 앱은 사람들이 이동해도 잘 바뀌지 않는 몇 가지 역할이면 충분합니다. 팀은 일상 업무 현실을 반영해야 합니다: Support Tier 2, EMEA 담당, 임시 큐 소유자 등.

최소 권한 원칙(least privilege)이 가장 안전한 기본값입니다. 많은 내부 앱은 세 가지 역할로 충분합니다:

• Viewer: 데이터를 읽고 검색을 실행할 수 있음
• Editor: 레코드를 생성하고 업데이트할 수 있음
• Admin: 설정, 사용자, 접근 규칙을 관리할 수 있음

각 역할이 허용하는 바를 평이한 언어로 문서화하세요. 이렇게 하면 그룹 이름이 바뀌었을 때 "깜짝 관리자" 권한이 생기는 것을 예방하고 나중에 리뷰하기가 쉬워집니다.

그룹 기반 접근: IdP 그룹을 어떻게 생각할 것인지

그룹 기반 접근은 앱이 사람별로 권한을 결정하지 않는다는 뜻입니다. 대신 IdP가 그룹 멤버십을 관리하고, 앱은 그 그룹을 역할과 팀에 매핑합니다.

먼저 그룹이 무엇을 부여하는지 결정하세요. 많은 도구에서는 하나의 그룹이 하나의 역할(예: "Support Agent")과 선택적으로 하나의 팀(예: "Tier 2")에 매핑됩니다. 핵심은 매핑이 지루하고 예측 가능해야 한다는 점입니다: 같은 그룹은 항상 같은 접근을 의미해야 합니다.

사용자가 여러 그룹에 속할 때

사람들은 종종 여러 IdP 그룹에 속합니다. 이를 해결할 규칙이 필요하고 그 규칙을 안정적으로 유지해야 합니다.

일반적인 접근 방식:

• 누적 규칙(Additive): 일치하는 모든 그룹의 권한을 합칩니다(권한이 좁게 범위가 정해졌을 때 유용).
• 우선순위 규칙(Priority): 가장 높은 우선순위 그룹 하나를 선택하고 나머지는 무시합니다(역할이 충돌할 때 유용).
• 하이브리드: 팀에는 누적을 적용하고 역할에는 우선순위를 적용합니다.

어떤 방식을 선택하든 문서화하세요. 나중에 이 규칙을 바꾸면 사용자가 갑자기 권한을 얻거나 잃을 수 있습니다.

확장 가능한 명명 규칙 사용하기

명확한 그룹 이름은 실수를 줄이고 감사를 쉽게 만듭니다. 실용적인 패턴 예:

• --

예: support-tool-prod-agent 또는 finance-tool-staging-viewer. 이렇게 하면 "Admins"처럼 모호한 이름을 여러 앱에서 재사용하는 일을 피할 수 있습니다.

사용자가 관련 그룹에 속하지 않으면 기본적으로 접근 금지(또는 제한된 게스트 상태)로 하고, 접근 요청 방법을 안내하는 메시지를 보여 주세요.

계정 연결: SSO 사용자를 앱 계정에 매칭하기

SSO는 사용자가 누구인지 증명하지만, 앱은 여전히 그 정체성을 어느 기존 계정에 붙일지 결정해야 합니다. 계정 연결이 없으면 식별자가 바뀔 때(이메일 변경, 이름 변경, 계열사 이동, IdP 변경) 동일인이 여러 계정을 갖게 될 수 있습니다.

하나의 안정적이고 고유한 키를 기본 매칭으로 선택하세요.

• OIDC의 경우 보통 IdP의 sub 클레임이 그 역할을 합니다.
• SAML의 경우에는 영구적인 NameID나 전용 불변 사용자 ID 속성이 자주 쓰입니다.

그 값을 "IdP 사용자 ID"로 저장하고 IdP issuer/entity ID와 함께 보관해 다른 IdP에서 같은 sub가 충돌하지 않도록 하세요.

이메일은 유용하지만 진실의 근원으로 취급하지 마세요. 이메일은 이름 변경, 도메인 마이그레이션, 합병 등으로 바뀌고, 별칭이나 공유 메일함 때문에 예기치 않은 매칭이 발생할 수 있습니다. 이메일로 매칭할 경우 IdP 신호가 확인되었을 때만 하거나 일회성 확인 단계를 고려하세요.

첫 로그인 시 대부분의 내부 도구는 다음 중 한 가지 온보딩 패턴을 택합니다:

• 자동 생성(Auto-create): 계정을 즉시 생성하고 최소 권한을 부여
• 초대 전용(Invite-only): 미리 생성되었거나 승인된 사용자만 로그인 허용
• 승인 흐름(Approval flow): 계정을 생성하지만 관리자 승인 전까지는 차단

안전한 기본은 자동 생성이지만 기본적으로 권한은 주지 않고, 이후 그룹이나 승인 단계로 권한을 부여하는 것입니다.

단계별: 클레임을 역할과 팀으로 매핑하기

좋은 클레임 매핑은 SSO를 투명하게 만듭니다: 사용자가 로그인하면 적절한 위치와 권한으로 바로 이동합니다.

먼저 접근 모델을 평이한 언어로 적어두세요. 각 역할(Viewer, Agent, Manager, Admin)과 각 팀(Support, Finance, IT), 누가 왜 그 권한을 가져야 하는지를 목록화합니다.

그다음 IdP가 실제로 보낼 수 있는 것을 확인하세요. SAML이나 OIDC에서 보통 안정적인 사용자 ID(subject 또는 NameID), 이메일, 하나 이상의 그룹 속성을 원합니다. IdP가 보내는 그룹 값의 정확한 문자열(대소문자 포함, 접두사 포함)을 캡처하세요. "Support"와 "support"는 다릅니다.

실용적인 흐름:

• 역할과 팀을 정의하고 각 항목의 소유자(변경을 승인할 사람)를 정합니다.
• IdP에서 사용 가능한 클레임과 정확한 그룹 이름을 목록화합니다(계약직, 공유 메일함 같은 엣지 케이스 포함).
• 매핑 규칙을 작성합니다: 그룹->역할, 그룹->팀, 여러 그룹이 일치할 때의 오버라이드 순서 등.
• 실제 IdP 계정을 가진 3~5개의 사용자 유형(신입, 관리자, 계약직, 관리자)을 사용해 테스트합니다.
• 각 테스트 사용자에 대해 예상 역할/팀 결과를 먼저 적고, 로그인해 결과를 비교합니다.

규칙을 구체화하기 위해 작은 예제를 하나 남겨 두세요. 예: 사용자가 okta-support에 속하면 Support 팀과 Agent 역할이 부여됩니다. okta-support-managers에도 속하면 Manager 역할이 Agent를 오버라이드합니다.

마지막으로 디버그 방법을 간단히 추가하세요. 수신된 원시 클레임(안전하게), 일치한 규칙, 최종 역할/팀 결과를 로깅하세요. 누군가 "로그인했는데 도구가 안 보여요"라고 하면 추측이 아니라 빠른 확인으로 원인을 찾을 수 있습니다.

클레임 누락 시 안전한 기본값

클레임 누락은 정상입니다. 서비스 계정엔 그룹을 보내지 않거나 커넥터가 필드를 생략하거나 사용자가 마이그레이션 중일 수 있습니다. "데이터 없음"을 "신뢰 없음"으로 처리하세요.

가장 안전한 기본은 거부(deny-by-default): 역할 없음, 팀 없음, 접근 금지입니다. 누군가 접근해서 권한을 요청할 수 있게 허용해야 한다면 읽기 전용 등 매우 제한적인 상태로만 허용하세요.

한 가지 동작을 선택해 문서화하세요:

• 로그인 차단 및 명확한 메시지 표시: "할당된 접근 권한이 없습니다. 관리자에게 문의하세요."
• 경고와 함께 제한된 접근 허용: 민감한 작업은 비활성화
• 사용자 레코드는 생성하되 역할/팀은 승인까지 부여하지 않음

절대 관리자 권한을 기본값으로 주지 마세요.

부분적인 데이터에 대비하세요. 이메일만 있고 그룹이 없으면 계정을 생성하고 승인으로 라우팅할 수 있습니다. 그룹은 있는데 안정적인 식별자가 없으면 기존 계정에 자동 연동하지 마세요. 잘못된 사람에게 권한이 붙을 수 있습니다.

실패에 대한 에스컬레이션 경로를 만드세요:

• 명명된 소유자(IT 또는 앱 관리자)가 접근을 승인
• 수동 역할 할당 흐름과 감사 메모
• 다음 로그인 시 클레임 재확인 방법
• "대기 중인 접근" 계정에 대한 타임아웃

변경, 제거, 오프보딩 처리

사람들은 팀을 옮기고 관리자도 바뀌고 퇴사합니다. SSO 설정은 이를 정상적인 일로 취급해야 합니다.

사람이 팀을 옮기면 다음 로그인 시 그룹 클레임을 재평가하고 현재 매핑을 적용하세요. 한 번 부여된 접근이 영구적으로 남지 않도록 하세요.

퇴사자의 경우 다음 로그인까지 기다리면 안 됩니다. 접근은 빠르게 종료되어야 하며, 보통 IdP에서 계정을 비활성화하면 앱도 즉시 차단하도록 처리합니다.

프로비저닝 해제는 예측 가능해야 합니다: 계정 비활성화, 팀 멤버십 제거, 감사 데이터 보존. 승인 내역, 댓글, 히스토리 같은 기록은 보존하면서 새 작업은 차단하세요.

계약직과 임시 접근에는 추가 주의가 필요합니다. IdP에서 기간 한정 그룹에 넣거나 역할에 검토 날짜를 붙여 프로젝트 종료 후 접근이 계속 남지 않도록 하세요.

실용적 오프보딩 정책 예:

• 로그인 시마다 클레임을 재확인하고 IdP에서 팀 멤버십을 갱신
• 사용자가 필수 그룹에서 제거되면 권한 즉시 박탈(다음 로그인 또는 다음 동기화 시)
• 계정을 비활성화하면서 감사 흔적과 소유권 이력 보존
• 계약직 접근에 종료 날짜 요구 및 갱신 전 검토
• 재무/관리자 같은 민감한 역할에 대해 정기적인 접근 검토 시행

흔한 실수와 함정

대부분의 SSO 장애는 SAML이나 OIDC 자체가 복잡해서가 아니라 앱이 사람, 그룹, 식별자에 대해 안전하지 않은 가정을 하기 때문에 발생합니다.

흔한 실수 중 하나는 역할 매핑과 팀 매핑을 섞는 것입니다. 역할은 "무엇을 할 수 있는가?"이고 팀은 "어디에 속하는가?"입니다. 팀 그룹을 곧바로 강력한 역할(예: Admin)에 매핑하면 그 팀에 속한 누구나 광범위한 권한을 가지게 됩니다.

또 다른 함정은 계정 연결의 유일한 식별자로 이메일만 사용하는 것입니다. 이메일은 바뀔 수 있고 별칭 때문에 중복이 생길 수 있습니다. 기본 키로는 IdP의 안정적인 사용자 ID(예: sub/NameID)를 선호하고 이메일은 표시/알림용으로만 사용하세요.

자주 발생하는 문제들:

• 그룹이 없을 때 기본값을 열어두는 것(누락 시 전체 접근 허용 X)
• 개발/스테이징/프로덕션에서 재사용되는 모호한 그룹명
• 그룹 멤버십을 단순 권한 목록으로 취급하고 각 그룹이 실제로 무엇을 의미하는지 검토하지 않음
• 다중 팀 사용자가 여러 영역에 접근해야 하는데 역할만 하나 허용해 권한을 과도하게 부여하거나 접근을 잃게 하는 경우
• 파트너와 계약직을 직원 전용 팀과 분리하지 않는 경우

출시 전에 엣지 케이스를 테스트하세요. 예를 들어 재무 분석가가 인시던트 대응 시 두 개의 팀과 하나의 승격된 역할을 필요로 할 수 있습니다. 규칙이 팀을 하나만 허용하면 접근을 잃거나 과도한 권한을 얻게 됩니다.

출시 전에 확인할 빠른 체크리스트

모든 사용자에게 SSO를 활성화하기 전에 각 팀의 테스트 계정으로 드라이런을 하세요. 대부분의 접근 문제는 신입, 역할 변경, 오프보딩 사례를 테스트하면 즉시 드러납니다.

먼저 계정 연결부터 시작하세요. 시간이 지나도 변하지 않을 고유 식별자를 하나 선택하고 고수하세요. OIDC에서는 보통 sub, SAML에서는 NameID나 특정 불변 속성입니다.

다음으로 클레임 누락 시의 동작을 결정하세요. 가장 안전한 기본값은 그룹이나 역할 클레임이 없거나 비어 있을 때 고급 권한(대부분의 경우 접근)을 주지 않는 것입니다. 필요한 경우 낮은 권한의 롤을 하나 만들어 민감한 작업을 보호하면서 최소한의 접근을 허용하세요.

간단한 사전 출시 체크리스트:

• 연결 식별자가 안정적이고 고유한지(로그에서 볼 수 있는지) 확인
• 그룹 클레임 누락 시 고급 권한을 부여하지 않는지 검증
• 관리자 접근은 명시적 관리자 그룹 매칭과 추가 승인 단계(수동이라도)를 요구
• 사용자가 그룹에서 제거되면 접근이 다음 로그인(또는 다음 동기화)에 떨어지는지 테스트
• 매핑 규칙을 한 페이지에 요약해 동료가 이해할 수 있게 작성

예시: Support와 Finance용 내부 도구와 SSO 그룹

매일 Support, Finance, 몇몇 매니저가 사용하는 운영 도구를 상상하세요. 사용자가 로그인하면 관리자가 수동으로 계정을 고치지 않아도 바로 올바른 화면과 동작을 얻기를 원합니다.

몇 개의 IdP 그룹을 만들고 앱 내 역할과 팀에 매핑하세요:

• ops-support -> 역할: Support Agent, 팀: Support
• ops-finance -> 역할: Finance Analyst, 팀: Finance
• ops-managers -> 역할: Manager, 팀: Management

실제 흐름은 다음과 같습니다.

이제 이메일 변경 사례: Omar가 [email protected]에서 [email protected]으로 변경되어도, 앱이 이메일이 아니라 안정적인 IdP 사용자 ID(예: OIDC의 sub 또는 SAML의 영구 NameID)를 사용해 계정을 연결하면 중복 계정이 생기지 않고 기록과 감사 내역이 유지됩니다.

추측 없이 접근을 검증하려면 사용자의 연결된 IdP 정체성, 수신된 그룹, 결과 역할 및 팀을 보여주는 "effective access" 뷰를 유지하세요. 문제가 있으면 IdP 문제인지 매핑 규칙 문제인지 누락된 클레임인지 빠르게 판별할 수 있습니다.

다음 단계: 조직 변화에도 접근을 예측 가능하게 유지하기

가장 어려운 부분은 첫 출시가 아니라 조직 개편, 새 팀, "임시" 예외를 거치면서 접근을 유지하는 일입니다.

한 페이지 매핑 문서를 유지하세요. 이 문서에는:

• 어떤 IdP 그룹이 어떤 앱 역할과 팀에 매핑되는지
• 클레임 누락 시 기본 동작(누가 변경을 승인하는지 포함)
• 각 고위험 역할의 소유자(재무 관리자, 사용자 관리자, 데이터 내보내기 권한 등)
• 계약직과 서비스 계정의 처리 방식
• 소스 오브 트루스(어디가 권한의 출처인지: IdP vs 앱)

경계가 분명한 한 부서를 대상으로 소규모 파일럿을 실행하고 엣지 케이스를 고친 뒤 확장하세요. 새로운 규칙을 함부로 만들지 마세요. 관리자나 고위험 역할은 월별, 일반 역할은 분기별로 정기 검토를 설정하세요.

내부 앱을 직접 개발한다면 역할, 팀, 비즈니스 로직을 가깝게 두어 변경을 쉽게 테스트할 수 있도록 하면 도움이 됩니다. AppMaster (appmaster.io)는 역할과 워크플로를 시각적으로 모델링하고, 요구사항이 바뀔 때 일회성 권한 수정이 쌓이지 않도록 백엔드, 웹, 모바일 코드를 재생성하는 옵션 중 하나입니다.