티스토리 뷰
프로젝트에서 SSO를 구현해야 하는 부분이 생겼다.
SSO가 뭔지도 모르는데 전체 사이트들이 공통으로 사용하는 SSO를 구현해야 하는 부분이라서
일단 SSO가 뭔지 조사하고 공부부터 진행을 해야 할 필요가 있어서 공부를 하는중에 너무 정리들을 잘 해놓은 자료들이 있어서 가져왔다.
SSO가 왜 필요한가
SSO가 없을 때의 상황을 먼저 머리속에 그려볼게요.
우선 카카오톡, 페이스북, 넷플릭스 라는 세 가지 서비스를 생각해볼까요. 세 개의 서비스는 각자의 방식으로 로그인을 요구합니다. 아래 사진 처럼요. 카카오톡을 쓰려면 카카오톡 아이디로 로그인을 해야하고, 넷플릭스를 쓰려면 넷플릭스 계정으로 로그인을 해야 해요. 또, 세 어플리케이션이 로그인을 처리하는 방식, 사용자 정보를 저장하는 방식 또한 각자 다를거에요.
그런데! 만약 세 어플리케이션이 독립적으로 작동하기는 하지만 서로 연관된 무언가 가 있다고 상상해보세요. 예를들어 모두 같은 회사에서 제공하는 서비스라면? 만약 지메일, 구글 드라이브, 구글 행아웃에 대해 각자 다른 아이디로 로그인을 해야 한다면? 사용하려고 생각해봐도, 만드려고 상상만 해봐도 몸서리치게 불편하네요..
- 사용자 입장에서는 <아이디-비밀번호> 세 쌍을 기억해야 하죠.
- 서비스를 만드는 입장에서는 로그인 화면 세 개, 데이터 베이스 세 개, 로그인 프로세스 세 개를 각자 구현 해야 합니다. 서비스끼리 데이터 싱크라도 구현 하려고 하면..;;
맞아요. 이렇게 되면 양쪽에게 다 불편하게 된 상황입니다.
SSO란 무엇인가
위에 기술한 것과 같은 불편을 해소할 수 있는 인증 방식이 SSO이고, Single Sign On의 약자입니다. 여러 서비스를 '로그인 한 번' 으로 이용하도록 하는 기술이에요. 각 어플리케이션에서 로그인/인증 부분만 떼어서 한 군데로 모아두는 방식입니다. 대략적인 그림을 일단 구경해주세요.
SP는 Service Provider의 약자입니다. 제가 위에서 얘기해온 '서비스', '어플리케이션'을 SSO 용어로는 SP라고 부릅니다. '전체 인증 흐름에서 무슨 역할을 담당하는 요소인가'의 관점에서 provider라는 단어가 따라붙은게 아닐까 생각합니다. 가운데에 IdP가 새로 생겼어요. IdP는 Identity Provider의 약자로, 각 SP들의 인증 관련 부분만 모아서 구현 해 놓은 것이라고 생각하시면 됩니다. '구현 해 놓은 것'이라고 적었지만 IdP 자체도 하나의 웹 서비스죠.
SSO는 어떻게 동작하는가
이제 준비운동이 끝났습니다. 제 생각엔 이제 나오는 부분을 읽으셔야 비로소, SSO가 이런 거구나, 하고 감이 오실 것 같아요. SSO가 어떤 흐름으로 동작하는지 예시를 드리겠습니다. 물론 실제 구글에서의 로그인 처리 방식과는 상관 없는, 제 상상 속의 시나리오 입니다.
먼저 구글 드라이브를 사용하는 시나리오를 생각 해 볼게요.
- 사용자가 SP(구글 드라이브)를 사용하려 합니다.
- 사용자의 세션 정보가 SP에 남아있지 않아서, SP는 사용자를 IdP(구글 통합 로그인 페이지)로 redirect 시킵니다
- 사용자의 세션 정보가 IdP에 남아있지 않아서, 사용자는 IdP에서 로그인(또는 어떤 방식으로든 '인증') 합니다.
- 인증이 완료되면, IdP는 사용자를 SP로 다시 redirect 시키며, 동시에 사용자의 '인증 정보'를 SP에게 전달합니다.
- 로그인 처리가 완료 되어 구글 드라이브를 사용할 수 있습니다.
그리고 이 직후에, 지메일을 사용하면 사용자 흐름은 아래와 같을 거에요.
- 사용자가 SP(지메일)을 사용하려 합니다.
- 사용자의 세션 정보가 SP에 남아있지 않아서, SP는 사용자를 IdP로 redirect 시킵니다.
- 사용자의 세션 정보가 IdP에 남아있습니다! 그러면 IdP는 사용자를 SP로 다시 redirect 시키며, 동시에 사용자의 '인증 정보'를 SP에게 전달합니다.
- 로그인 처리가 완료 되어 지메일을 사용할 수 있습니다.
SSO를 어떻게 구현할까
SSO 시스템을 구현할 때의 가장 중요한 포인트는, 제 생각에, IdP에서 SP로 사용자 인증 정보 전달을 처리할 때 의 보안 입니다. 이 부분은 여러 표준, 프레임워크 등에 의해 구현할 수 있는데요, 그 중에 대표적으로 SAML, OAuth, JWT등이 있습니다. 이 부분에 대해서는 따로 포스팅을 할 계획입니다.
출처 : hanee24.github.io/2018/08/04/sso/
SSO의 구성 요소
(1) 사용자 통합 로그인
(2) 인증 서버
(3) 통합 에이전트 : 각 정보 시스템에 대한 정보 관리
(4) LDAP(Lightweight Directory Access Protocol) : 네트워크 상의 자원을 식별하고 인가된 사용자만 접근하도록 하는
네트워크 디렉토리 서비스
SSO의 기술 요소
- 인증 : PKI(Public Key Infra structure), 생체 인식, OTP(One Time Password)
- 관리 : LDAP(Lightweight Directory Access Protocol), 쿠키(Cookie)
- 암호화 통신 : SSL(Secure Socket Layer), IPSec(IP Security Protocol)
SSO의 구축 유형
1) 인증 대행 모델(Delegation)
- 인증 방식을 변경하기 어려울 경우, 많이 사용
- 시스템 접근 시, 통합 Agent가 인증 작업을 대행
2) 인증 정보 전달 모델(Propagation)
- 웹 기반의 시스템에 주로 사용
- 미리 인증된 토큰(Cookie 기능 이용)을 받아서 각 시스템 접근 시, 자동으로 전달
Cookie를 이용한 SSO 구현 시, Cookie 보안 방법
- 데이터 기밀 유지(Data Confidentiality) : 토큰은 주요 암호 알고리즘(AES, SEED)과 128bit 이상의 키로 암호화 되어야 합니다.
- 데이터 무결성(Data Integrity) : 토큰은 MAC 등을 포함해 데이터의 무결성을 보장해야 합니다.
- 사용자 주소 제한이나 유효 시간 제한 같은 보안 기술을 사용하여, 토큰을 네트워크에 노출시키지 않아야 합니다.
출처: https://toma0912.tistory.com/75 [토마의 개발노트]
'프로그래밍' 카테고리의 다른 글
SPRING BOOT 와 Keycloak를 이용한 SSO 구성 자료 (31) | 2020.11.06 |
---|
- Total
- Today
- Yesterday
- 카페24
- static
- 오늘의 공부
- 스프링
- FCM
- character varying
- 개발 공부
- 도메인 구입
- LocalDateTime
- sso
- value
- 스프링부트
- 도메인 구입 방법
- firebase
- 오버로드
- 오버라이드
- 타사 호스팅 연결 방법
- Overloading
- Overriding
- Integer
- static변수
- @value
- 개발 공부를 위한 다짐
- 개발자의 삶
- java8
- decimal
- 호스팅 구입 방법
- NUMERIC
- 이직
- spring boot
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |