SSO로 팀 로그인
만들게 될 것
섹션 제목: “만들게 될 것”이 튜토리얼을 마치면 다음을 갖추게 됩니다.
- Control Center 서버와 ID 공급자 사이의 SAML 연결(예시로 Okta를 사용합니다),
- 첫 로그인 시 자동으로 프로비저닝되는 사용자 한 명,
- 그리고 의도적으로 선택한 워크스페이스 멤버십 정책.
관리 권한이 있는 서버(서버 소유자 — 설치의 운영자)와 구성할 수 있는 IdP 애플리케이션이 필요합니다. 20분 정도 걸립니다.
1단계: 싱글 사인온 설정 열기
섹션 제목: “1단계: 싱글 사인온 설정 열기”Control Center에 로그인한 다음 설정 → 서버 → 싱글 사인온으로 이동합니다. 화면은 SAML과 OpenID Connect 사이를 전환하며, 여기에 사용자 프로비저닝(SCIM) 카드도 있습니다. SAML을 그대로 두십시오.
이 화면의 모든 설정은 서버 전체 범위입니다. 하나의 IdP가 모든 워크스페이스의 사용자를 인증하므로 서버 소유자만 편집할 수 있습니다.
2단계: IdP 메타데이터 붙여넣기
섹션 제목: “2단계: IdP 메타데이터 붙여넣기”Okta에서 앱의 Sign On 탭을 열고 메타데이터 XML을 복사합니다(또는 내려받아 파일 내용을 붙여넣습니다). Control Center로 돌아와 IdP 메타데이터 XML에 붙여넣고 연결 테스트를 누릅니다.
토스트에는 IdP의 로그인 엔드포인트가 보고됩니다. 이는 메타데이터가
파싱되었고, 인증서를 읽었으며, 서버가 이에 대한 로그인 요청을 만들 수
있다는 증거입니다(이 테스트는 브라우저 왕복을 제외한 모든 것을
검증합니다). 실패한다면 그 XML이 완전한 EntityDescriptor가 아니었던
것입니다(Okta의 SAML 탭에서는 이를 “Metadata URL”이라고 부릅니다. URL을
열어 제공되는 내용을 복사하십시오). OpenID Connect의 같은 버튼은 대신
발급자의 디스커버리 문서를 확인합니다. 만료가 임박한 인증서까지 잡아내고
IdP가 Control Center를 인식하는지도 보려면
6단계의 검사기를 사용하십시오.
3단계: IdP에 Control Center 등록하기
섹션 제목: “3단계: IdP에 Control Center 등록하기”SP 메타데이터 복사를 누르고 Okta 쪽을 구성하는 담당자에게 전달하십시오(또는 상대가 요청하는 두 값을 읽어 주십시오).
- ACS URL:
https://<your-server>/saml/acs - 엔터티 ID:
https://<your-server>/saml
이 URL은 사용자 브라우저가 도달하는 오리진에서 파생됩니다. 서버가 터널이나 리버스 프록시 뒤에서 실행된다면 오리진이 안정적인지 확인하십시오 (설정 → 서버 → 연결 및 상태 → 이 서버 공유에 공개 URL이 표시됩니다). 아니면 SP 엔터티 ID 필드에 엔터티 ID를 명시적으로 고정하십시오.
4단계: 로그인이 부여하는 것 선택하기
섹션 제목: “4단계: 로그인이 부여하는 것 선택하기”두 가지 정책이 첫 로그인의 동작을 결정합니다.
- 첫 로그인 시 모든 워크스페이스에 사용자 추가 — SSO가 곧 신뢰인 단일 팀 배포에서는 켜 두십시오. 여러 팀이나 고객이 서버를 공유한다면 끄십시오. 그러면 새로 들어오는 사람마다 명시적인 워크스페이스 초대가 필요하며, 이것이 더 안전한 기본값입니다.
- 첫 로그인 시 알 수 없는 사용자 프로비저닝 — 기본적으로 켜져 있습니다. 이미 계정이 없는 사람을 거부하려면 끄십시오.
선택적으로 그룹 이름을 담은 속성을 매핑하고(Okta에서는 보통 groups)
매핑으로 그룹을 역할로 변환할 수 있습니다. 예를 들어
{"platform-leads": "admin"}입니다. SSO로는 소유자 역할을 부여할 수
없습니다.
5단계: 활성화하고 로그인해 보기
섹션 제목: “5단계: 활성화하고 로그인해 보기”SAML로 로그인을 켜고 연결 저장을 누른 다음, 시크릿 창에서
https://<your-server>/saml/login을 엽니다. Okta에서 로그인하면 웹
클라이언트로 되돌아옵니다 — 로그인된 상태이며, 계정이 생성되고 선택한
정책에 따라 멤버십이 부여되어 있습니다.
웹 연결 화면에서는 서버 주소를 입력하는 순간 같은 진입점 (SAML(으)로 로그인)이 나타납니다 — 폼은 서버가 제공하는 방식에 맞춰 바뀝니다(OpenID Connect에서는 OpenID Connect(으)로 로그인이 표시됩니다). 이 버튼은 새 탭에서 로그인을 엽니다. 왕복이 끝나면 기다리던 탭이 세션을 자동으로 이어받습니다. 데스크톱의 서버 설정 화면도 같습니다. 서버 URL을 입력하면 SAML(으)로 로그인 버튼이 나타나고, 이 버튼이 브라우저를 열며, 왕복이 끝나면 앱이 로그인됩니다.
6단계: 이 페이지에서 확인하기
섹션 제목: “6단계: 이 페이지에서 확인하기”SSO를 배포하기 전이나 로그인에 실패했을 때 여기서 각 요소를 확인하십시오. 검사기는 전적으로 브라우저에서 실행됩니다. 이 탭에 붙여넣은 메타데이터를 읽고 서버와 같은 규칙을 적용합니다. 서버 주소를 입력하면 해당 서버에 SAML 로그인이 켜져 있는지도 물어봅니다.
앱의 연결 테스트가 보지 못하는 것을 잡아냅니다. 만료가 임박한 서명 인증서, 서명된 요청을 고집하는 IdP, 그리고 테스트 로그인으로 IdP가 Control Center를 인식하는지 여부입니다.
Runs in your browserYour metadata is read in this tab and never uploaded. Add a server address and your browser also asks that server which sign-in methods it offers.
Test sign-in at your IdP
- Your IdP's sign-in page: it recognizes Control Center's entity ID. You can close the tab.
- An error at your IdP: it names what to fix, usually an unknown entity ID (Entra: AADSTS700016) or a user not assigned to the app.
- Your server's "Sign-in failed" page: also a pass. The IdP accepted the request and posted back to your ACS URL; your server refuses it only because this page started the sign-in, not your server.
다음 단계
섹션 제목: “다음 단계”- IdP에 수명주기 제어까지 맡기려면: SCIM으로 사용자 프로비저닝.
- IdP가 SAML 대신 OpenID Connect를 사용하십니까? OpenID Connect 공급자 연결.
- 브라우저 왕복이 실제로 무엇을 검증하는지 궁금하십니까? 싱글 사인온의 동작 방식.