[ Architecture, Technology ,Web ] SSO(Single Sign On) 그리고 SAML에 대해

이미지
이번 프로젝트 내부에서 어쩌다보니  유저 인증 관련 업무를 담당하게 되었고, 해야하는 업무는 내부에 사용했던 적이 없던  새로운 개발 플랫폼에서  SSO의 프로토콜 중  SAML을 이용해 앱의 인증을 구현해야만 했다. SSO를 생각해본적 조차 없는 상황에 이를 새로운 개발 플랫폼에 도입해야 했기 때문에 많은 시행착오를 겪었으나 구현에 성공하였으며 덕분에 SSO에 대한 전반적인 지식을 쌓을 수 있었다. 이번에는 그러한 과정에서 나온 지식들과 경험을  공유하고자 한다. SSO에 대한 정의 먼저 사전적 정의 부터 살펴보자. 다만, 기술적인 용어다보니 자주 사용하는 옥스포드 사전에 정의를 찾을 수 없기 때문에  검색으로 찾을 수 있는 정의를 몇 가지 살펴보고 교차 검증을 해보자. 첫 번째 정의를 살펴보자. Single sign-on (SSO) is an identification method that enables users to log in to multiple applications and websites with one set of credentials.  SSO는 웹사이트에서 한 번의 인증(one set of credentials)으로 복수의 어플리케이션에 로그인 할 수 있는 인증(identification) 방법(method) 이다. 두 번째는 위키피디아의 정의이다. Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems. SSO는 독립적이지만 연관되어있는 몇몇 소프트웨어에 대해 하나의 ID로 로그인을 할 수 있도록 하는 인증 구조(scheme) 세부 설명에 조금 차이가 있어 보이지만 전체적인 틀은 매우 비슷해 보인다.  몇 가지 포인트가 되는 단어를 추출해 이를 연결해보자면 아래와 같은 의미를 산출 할 수 있다. 독립적이지만 연관되어 있

[ Django, Python ] 이쯤에서 분석해 보는 Django 튜토리얼 예제 (①~④) ④ : 전체적인 청사진 그리기, start_django 앱(App) 청사진 분석, polls 앱(App) 청사진 분석

Django 청사진 그리기 및 분석 : 전체적인 청사진 그리기

지금 까지 해서 세세한 부분까지 분석해봤다

그럼 이를 바탕으로 이제 조금 넓게 청사진 그려보자.


내 나름대로 가장 중요한 파일들 그리고, 그 파일들안의 코드들을 나누어 정리해 봤다.

여기서 가장 최상위 디렉토리start_django프로젝트를 생성할 때
입력했던 이름이고

그 하위의 디렉토리 start_django프로젝트 생성시, 자동으로 생성되는 디폴트 App이며
polls는 이전 예제에서 다루었던 투표(vote)기능을 만들기 위해 생성했던 App이다.


그럼 하나 씩 쪼개 보면서 살펴보자.

Django 청사진 그리기 및 분석 : start_django (App) 청사진 분석


start_django (App)부터 살펴보자.

이전에서부터 계속 언급했듯이, App은 프로젝트 생성시
생성한 프로젝트의 이름으로 자동 생성되는 디폴트 App이다.

따라서 만약 이름이 stay_app으로 프로젝트를 생성했다면
동일하게 이 App의 이름은 stay_app으로 자동으로 생성된다.

여러가지 생성되지만,

가장 주목해야 하는 곳은 urls.pysettings.py이다.


먼저 start_django (App)urls.py에서는 App들의 경로(Path)설정할 수 있다.
여기서 경로를 설정해주지 않으면 각 App들로 이동할 수 없다.

따라서 Django의 디폴트 App인 이 start_django라는 이름의 App
App들을 연결시켜주는 App이다.

위의 사진에서 볼 수 있듯이 예제에서 프로그래밍 했던 
polls App등록되어 있는 것을 확인 할 수 있다.


여기서 admin AppDjango에서 제공해주는 관리자 기능 애플리케이션이다.


다음은 settings.py를 살펴보자.

여기서는 이 프로젝트에 대한 여러가지 설정(setting)을 할 수 있는 공간이다.
INSTALLED_APPS이외에도 설정할 수 있는 변수들이 많이 있지만

반드시 설정해주어야 하는 곳이 이 INSTALLED_APPS라는 변수이다.

위의 사진을 보면 Django에서 제공해주는 관리자 애플리케이션 admin App

예제에서 프로그래밍 했던 투표 Apppolls App등록되어 있는 것을 확인 할 수 있다.

Django 청사진 그리기 및 분석 : polls (App) 청사진 분석


다음으로 polls (App)을 살펴보자.

polls 라는 애플리케이션이 사실상 예제에서 다루었던 App이다.

여기서부터 DjangoMVT(Model View Template)가 보일 것 이다.


그리고 DjangoMVT 아키텍쳐에서 본적이 있는 urls도 보인다.


먼저 Model이다.

여기서 ModelMVT패턴의 그 Model역할을 맡고 있는Model이 맞다.

일반적으로 class 기반으로 정의(define) 된다.
위의 사진에서 보이듯이 각 class의 지역변수의 TypeDBType비슷한 것을 확인 할 수 있다.

Django에서는 이 Model을 가지고 테이블생성해주는 마이그레이션(migration) 기능을
지원해주는데

마이그레이션(migration) 기능을 이용하면
Class기반으로 Model를 정의한 이름으로 테이블 명으로
class의 각 지역변수들을 컬럼명으로 테이블을 생성 해준다.

따라서 웹 개발 프레임워크로 Django선택한다면 굳이 테이블 생성을 위해

테이블을 생성하러 DB 까지 들어가 Sql문을 작성할 필요가 없다는 말이 된다.


다음으로 View
위와 동일하게 MVT 패턴View의 역할을 맡고 있는 그 View.

Viewfunction 기반class 기반 이 두 가지를 선택할 수 있다.

class 기반을 사용할 때는 사용자에게 보여줄 필요가 있는 View일 경우,
function 기반을 사용할 때에는 사용자에게 보여줄 필요가 없는 View
, 데이터 처리와 같은 것 일 때 사용한다.

고 지금까지 했던 예제를 통해 추측해 볼 수 있다.



다음은 template.
동일하게 MVT 패턴Template의 역할을 맡고 있는 Template.

template들은 html 태그DTL(Django Template Language)구성되어 있다.
DTLJAVA기반 웹 프레임워크인 Spring에서 자주 사용하는 JQuery유사하다.




마지막으로 urls이다.

왜 뜬금 없이 이 녀석이 나오느냐라고 하는 사람이 있을지도 모르겠지만

Django 프레임워크에서 매우 중요한 역할을 한다.

urls가 실제 Django상호작용을 하기 때문이다.

이 다음에 더 넓게 Django 아키텍쳐를 보면서 청사진을 그릴 것이기 때문에
그때 한번 더 언급하기로 하겠다.




이렇게 해서 이번에는 이전 보다 좀 더 넓은 관점에서 분석해봤다.

위에서도 말했지만 다음은 마지막으로 Django 아키텍쳐를 보면서
사실상 가장 넓은 시야에서 분석해 보려고 한다.

그 다음 이번 분석글을 끝내려 한다.

물론 분석글이 끝난다고 해도 공식 도큐먼트에 예제는 남아있기 때문에
더 진행할 것이다.

이 블로그의 인기 게시물

[ Web ] 웹 애플리케이션 아키텍처 (Web Application Architecture)

[ Web ] 서버 사이드(Sever Side) ? 클라이언트 사이드(Client Side)? 1 [서론, 클라이언트 사이드(Client Side)]

[ Web ] 웹 애플리케이션? 웹 사이트?(Web Application? Web Site?)