글

[ 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 튜토리얼 예제 (①～④) ⑤ : Django MVT 아키텍쳐에서 App시점 청사진 그리기

-
이미지
・ Django MVT 아키텍쳐에서 App 시점 청사진 그리기  : App 시점 청사진 마지막으로 각 App 의 시점 에서 MVT 패턴 아키텍쳐 의 청사진을 그려본다 면 위와 같은 청사진 을 그릴 수 가 있다 . 위의 그림에서 디폴트 (default) App 은 제외 했으며 예제에서 다뤘던 앱이 polls 라는 App 밖에 없어 , 좀 더 이해를 편하게 하기 위해 임의의 xxx 라는 App 을 만들었다 . 단순히 하나의 App 만 있으면 이해 가 힘들 수 도 있다 고 생각해 임의의 xxx 라는 이름의 App 을 만들어 붙여넣었다 . 아마 이 그림을 이해할 수 있다면 , 사실상 Django 는 끝이 났다고 볼 수 있다고 감히 말 할 수 있다 . 왜냐하면 이 이상은  어떤 라이브러리를 써서,  어떤 비즈니스 로직을 만들 것인지에 대한 각 개발자들의 몫 이다 . 여기에 완전히 다른 한 개의 App 을 프로그래밍해서 넣건 다른 누군가의 App 을 가져와서 넣건  이 문제는 각 프로젝트의 목표에 맞게 개발자 들이 선택 하면 된다 . 그리고 만든 App 은 디폴트 App 의 urls.py 에 연결 시켜주기만 하면 끝이다 . 다음은 개발자의 몫이 아닌 디자인의 영역이다 . 추가로 분석은 딱히 하지 않겠다. 이미 이전 글에서 대략적으로 분석을 해 놨기 때문에 그 쪽을 보기 바란다.
자세한 내용 보기

[ 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.py 와 settings.py 이다 . 먼저 start_django 앱 (App) 의 urls.py 에서는 App 들의 경로 (Path) 를 설정 할 수 있다 . 여기서 경로를 설정해주지 않으면 각 App 들로 이동할 수 없다 . 따라서 Django 의 디폴트 App 인 이 start_django 라는 이름의 App 은 각 App 들을 연결시켜주는 App 이다 . 위의 사진에서 볼 수 있듯이 예제에서 프로그래밍 했던  polls App 이 등록 되어 있는  것을 확인 할 수 있다 . 여기서 admin App 은 Django 에서 제공 해주는
자세한 내용 보기

[ 생각 ] 각 나라의 우선시하는 정의(Justice)에 대해

-
이미지
최근에 정의(Justice)에 대한 생각을 하다가 문득 각 나라의 정의(Justice)에 대한 생각이 떠올라서 그 주제로 이야기를 해보려 한다. 물론 정의(Justice)는 개인이 정의(define)하기 나름이다. 하지만 같은 문화권 그러니깐 같은 나라의 사람이라면 그 정의의 어떤 공통점들이 보인다. 내가 본 사람들은 한국인, 일본인, 중국인, 미국인 이다. 따라서 이 네 국가의 사람들이 기본적으로 중요시하는 원칙 그러니깐 그 나라의 정의(Justice)에 대해 이야기 해보려한다. 물론 정의를 가치 평가는 할 수는 없음은 물론이고 그게 그 나라의 정의(Justice)다!! 라고 자신있게 주장하는 것은 아니다. 단지 나는 개인적인 느낌을 적어 놓을 뿐이다. 한국의 정의(Justice)는 "공정함"이다. 따라서 어떤 사안을 평가 할때 이 행위가 혹은 사람이 "공정"한지 혹은 "공정한 사람"인지 아닌지를 먼저 생각한다. 그래서 어떠한 이유던 간에 이 정의(Justice)에 반하는 행위를 하거나 그런 사람이 있다면 한국 사회에서 좋은 평가를 받을 수 없다. 다만 너무 공정함에 집착하다 보니, 공정함을 따지기 힘든 사안에서도 공정함을 따지다가 앞으로 못 나아가는 느낌이 든다. 일본의 정의(Justice)는 "상대를 생각하는 어떤 것"이다. 따라서 어떤 사안을 평가 할때 이 행위 혹은 사람이 "상대를 생각해서 하는 어떤 것"에서 나온 행위인지 혹은 "상대를 생각하는 어떤 것" 을 가지고 있는 사람인지가 중요하다. 이 행위는 대부분 걷으로 드러나는 행위를 말하지만, 내면도 중요시 여긴다. 그래서 어떠한 이유던 간에 이 정의(Justice)에 반하는 행위를 하거나 그런 사람이 있다면 일본 사회에서 좋은 평가를 받을 수 없다. 다만, 너무 상대를 생각하다보니 능력이 있음에
자세한 내용 보기

[ Django, Python ] 이쯤에서 분석해 보는 Django 튜토리얼 예제 (①～④) ③ : index.html, detail.html, results.html Template 파일과 브라우저 화면 분석, function 기반 vote View와 브라우저 화면 분석

-
이미지
・ 실제 화면과 Model View Template 의 비교 분석 : index.html Template 파일과  브라우저 화면 분석 자 그럼 이제 정말로 각 template 가 실제 어떻게 브라우저에 표시되는지 알아보자 . 먼저 투표 화면 부터 확인해보자 . Django 서버 를 가동하고 브라우저에서 polls 의 메인화면으로 들어가보자 . 정상적으로 프로그래밍 되어 있다면 위와 같은 polls App 의 화면이 표시될 것 이다 . 이 화면의 Template 은 아래와 같다 . Template 디렉토리 의 polls 디렉토리 의 index.html 에 프로그래밍 되어 있는 것이 우리가 실제로 보이는 브라우저 상 에 보인다 . 다음으로 이 화면에 연관되어 있는 View 는  Class 기반의 IndexView 라는 이름의 View 이다 . 이 화면의 경우 Model 은 존재하지 않는데 , 이유는 이 화면은 단순히 투표 (Vote) 하기 위한 화면 으로 들어가는 기능만 제공하기 때문이다 . 이 Class 기반의 IndexView 라는 이름의 View 가 Django 를 통해 실제 사용자의 요청 (request) 에 따라 브라우저에 보내 준다 (response) . 브라우저의 What’s up? 이라는 텍스트를 클릭하면 아래의 그림과 같은 투표 (Vote) 할 수 있는 화면 으로 넘어 갈 수 있다 . ・ 실제 화면과  Model View Template 의 비교 분석  : detail.html Template 파일과  브라우저 화면 분석 먼저 유심히 살펴봐야할 부분은 빨간색 박스 의 URL 이 실제 어떻게 표시되느냐 의 부분이다 . 일단 urls.py 파일 을 살펴보자 . 위의 path() 함수 를 살펴보면 , URL 이 ‘<int:pk>/’ 으로 프로그래밍 되어져 있는 것을
자세한 내용 보기