박종명의 아름다운 개발 since 2010.06

세종대왕의 한글 창제를 반대했던 집현전 학자들의 소견내용이다.

지금보면 사대주의에 과거지향적인 마인드에 기득권 유지에... 어처구니없는 소견인 것 같지만, 당시에 시대상황으로는 그럴만 했을 것이다.

이 글을 보고 느낀 점은, 반대 소견을 피력했던 집현전 학자들의 한계가 아니라 그럼에도 불구하고 한글 창제를 현실화 시킨 세종대왕의 뛰어난 역량에 감탄이 나오는 것이다.

개인적으로 책으로 학습하는 것을 좋아한다.

저자의 혼신의 노력이 들어간 책이야말로 그 어떤 학습도구보다도 진실성과 책임감이 있기 때문이다.

그리고 지식을 체계적으로 정립하는 데 책 만한 것이 없다.

그간, 관심 있는 여러 기술 분야의 책들을 봐 왔다. 그 중 닷넷 분야의 책을 몇 권 소개할까 한다.

닷넷 책도 수 십권을 봐 왔지만, 여기서 소개하는 책들은 개인적으로 감명을 받았거나 가치를 높이 두거나 어떤 식으로든 나에게 유익하고 많은 도움이 되었던 책들을 엄선한 것이다.

온전히 개인적인 기준으로 선정한 것이며, 내가 접한 책들 중에서만 엄선한 것이다.

내가 못 본 책 중에서도 많은 훌륭한 책들이 있을 것이며, 반대로 여기에 소개되지 않은 내가 본 책들도 그 만의 가치는 다 가지고 있다. 모든 책에서 적어도 한 가지 이상은 배울 수 있으며 절대적인면에는 모두 가치 있는 것이다.

잘 동작하는 WCF 서비스를 웹 프로젝트에서 참조하려고 하니, 다음과 오류를 뱉으면서 참조가 되지 않는다

이 WCF 서비스는 클라이언트 테스트 용으로 콘솔 응용프로그램과 윈도우 응용프로그램에서 모두 참조해서 잘 사용하던 것이었다.

오류를 내뱉은 이번 사례는 'ASP.NET MVC4 인터넷 응용프로그램'이다.

혹시나 해서 ASP.NET MVC3 인터넷 응용프로그램으로 WCF 참조를 시도해 보니.. 이건 잘 된다. 음.. 뭥미..

게다가 ASP.NET MVC4 Web API'로 시도해 보니, 이건 안되긴 하는데 오류 내용이 조금 다르다

결국 WCF를 소비하는 클라이언트가 ASP.NET MVC4 일 경우 (조금씩 다르긴 하지만) 이와 같은 문제가 발생 하는 것을 확인하였다

이것은 WCF를 참조할 때 기본으로 설정되어 있는 '참조된 모든 어셈블리의 형식 재사용' 옵션 때문이라 하는데, 이 옵션을 제거하면 더 이상 참조 오류는 발생하지 않는다

어셈블리 재사용 옵션은 클라이언트에 동일 타입이 이미 존재할 경우, WCF 참조로부터 자동으로 생성되는 타입에서 제외되어 기존 클라이언트의 것을 재사용할 수 있도록 하는 편리한 기능인데 이 부분이 문제가 된다니 의아스럽다. 이 옵션의 자세한 내용은 아래 블로그 글에서 확인할 수 있다.

> 관련 글: VS.NET 2008 - 서비스 참조시 기존 데이터 컨테이너 DLL 사용

그리고 오류 내용을 보면, DotNetOpenAuth.AspNet 어셈블리의 종속성 문제인 듯 하여 관련 어셈블리만 재사용하지 않도록 설정해도 문제는 동일하게 발생한다.

결국 몇 번 시도 끝에 문제가 되는 어셈블리를 찾게 되었다.

각각의 환경에서 위에 나열한 어셈블리만 재사용에서 제외해 버리면 잘 동작한다

아래 화면은 ASP.NET MVC4 인터넷 응용프로그램에서 Microsoft.Web.WebPages.OAuth를 제외한 모습이다

뭐.. 개별 프로젝트의 현상과 바로 적용 가능한 적절한 해결책은 찾았으나, 근원적인 원인에 대한 이해가 필요하다. 일단 여기까지 하고, 다음 기회에 알아 보기로 한다. 

모든 분야의 엔지니어링 원리는 다음과 같이 단계적인 발전 과정을 거치게 된다

공학의 ACE라 하는데, 각 단계는 다음과 같은 의미를 가지고 있다

Art: 개인의 재주에 의존하는 단계

Craft: 차츰 과학적 원리가 도입된 숙련공이 일반화 되는 단계

Engineering: 공학적 원리가 적용되는 단계

소프트웨어 공학 서적에 나오는 내용으로 소프트웨어 역시 다른 엔지니어링 분야의 단계와 같은 발전 과정을 거친다는 것이다. 타 산업분야에 비할바는 아니지만, 소프트웨어 공학이라는 개념이 탄생한지도 50년이 다 되어가니 적지 않은 세월이 흐른 셈이다.

소프트웨어 산업의 중심에 있는 우리 프로그래머들은 과연 이러한 체계적인 공학 원리에 충실하고 있는지 생각해 봐야 할 문제이다. 국내 환경이 공학적 접근 노력을 시도할 수도 없을 만큼 스펙타클하게 운영되고 았는 현실인지라 힘에 겨운 것도 있지만, 그렇다고 환경만을 탓하고 있기엔 우린 너무 빨리 늙어 버린다. ㅎㅎ

소프트웨어 공학이라는 개념이 탄생하고 뛰어나신 분들이 연구에 연구를 거듭하는 것은 결국 소프트웨어의 품질과 생산성이라는 두 마리 토끼를 어떻게 쉬이 잡을 것이냐를 위한 것인데 프로그래머들의 현실적인 생산성 문제로 공학적 접근을 하지 못한다는 것은 뭔가 앞뒤가 맞지 않다

소프트웨어 공학이 프로그래밍 코드보다는 개발 공정에 초점이 맞춰져 있어 내일 당장 동작하는 코드를 내뱉어야 하는 프로그래머들에게는 (뭔가.. 그럴싸 하다는 건 알겠으나...) 체감되지 않기도 한다

역사가 깊은 건축 공학의 많은 개념이 소프트웨어 공학에도 접목되는데, 예를 들어 빌딩을 지으면서 공학적 접근을 하지 않을 수는 없을 것이다. 그럼 아파트 혹은 빌라라면?? 아니면 집에서 키우는 개를 위한 개집을 짓는다면??

산업의 발전을 그렇다치고, 우리 개인의 발전 과정과 현 상태는 어떤가?

A와 C단계를 겨우겨우 오르락 내리락 하지 않는지, 자문해 볼 일이다.

작은 슈퍼를 운영하더라도 경영 마인드가 있어야 한다는 예기가 있다

비슷하게 풀어보면,

개집을 지어도 빌딩 건축업자 마인드가 있어야 있어야 하지 않을까?

오버거나 말거나...

주말에...

안보는 책 좀 버려달라는 와이프의 요구에 따라, 오래전에 구입하고 최근 몇 년간 한번도 들춰보지 않은 책들을 책장에서 과감히(?) 꺼냈다

대부분이 평균 10년 안팎의 책들이며, 당시에는 유용하게 봤으나 최근에는 거의 볼일이 없는 책들이다

기술보다는 추억(?) 때문에 버리기 싫어서 이사하면서도 계속 함께했던 녀석들이다

그러나 버리는 것도 기술이라는 어떤 글이 생각나기도 하고, 몇 년간 안 봤으면 더 이상 볼일도 없을 것이라는 결정에 따라 처분하기로 했다

책을 정리하며 하나하나 들춰 보니, 옛 생각이 밀려 들었다. 그땐 그랬지... ㅎㅎ

군데군데 쳐진 밑줄과 낙서에 가까운 메모들을 보며, "지금은 다 잊어 버렸어" 한다.

버리는 책들은 무거우나 나의 지식은 가볍구나...

ㅎㅎ 재밌군...

-----------------------------------------------------------------------------------------------------------------------

“재미있네.”(속뜻: 내 생각은 달라)

“내 생각은 다른데.”(내 생각은 정말 많이 달라)

“내 생각과 많이 다르네.”(네가 맞을지도 모르지만 난 관심 없어)

“틀렸어.”(내가 원하는 답이 아니잖아)

“사람이 융통성이 있어야지.”(하고 싶지 않아도 시키면 해)

“나를 납득시켜 봐.”(네가 뭐라는지 하나도 모르겠고, 너도 마찬가지지?)

“더 큰 그림을 보라니까.”(회장님이 원하는 방향을 모르나?)

“결정했네.”(내 뜻은 확고하니까 더 이상 왈가왈부하지 마)

“나중에 더 얘기해 보자고.”(그랬다간 죽을 줄 알아)

“e-메일로 보낸 건 무슨 뜻이야?”(간단히 요약해서 얘기해 봐. 난 아직도 e-메일 볼 줄 몰라)

모니터링 시스템에 알림을 구현하는 독립된 서비스가 존재한다.

이 서비스는 Email, SMS, Messenger와 같은 수단으로 알림 전송을 대행해 주는 역할을 하고 있다.

대략적인 내부 구현은,

Mail의 경우 사내 SMTP 서버를 이용하여 메일 전송을 수행하며, SMS의 경우 3rd Party에서 제공하는 모듈을 이용하고 Messenger의 경우 사내 메신저가 노출하는 연동 인터페이스로 메시지 전송을 수행한다.

서비스는 잘 동작하고 있지만, 문제는 환경의 변화에 유연하지 못하다는 것이다.

다시말해 Mail, SMS, Messenger의 연동 환경이 달라진 환경에 알림 서비스가 설치되어야 한다면 서비스의 내부 코드도 같이 변경되어야 하고 다시 빌드해서 배포해야 한다는 것이다.

따라서 알림 서비스의 유연성을 좋게 하기 위해 인터페이스 기반으로 동작하도록 하는 것이 첫번째 할 일이다.

(코드를 단순화 하기 위해 Email 전송 부분만을 예로 든다. 구차한 매개변수도 역시 생략한다)

* NotificationService

이제 실제 이메일 전송을 수행하는 구상 클래스를 생성한다. 이 구상클래스는 환경에 따라 달라질 수 있는 부분으로 교체가능한 모듈이 된다

* EmailSenderA

이제 메일 서비스를 사용해보자.

* NotifcationAgent

동작은 잘 하지만, 역시 구상 객체에 의존하게 된다(new NotificationMehodA.EmailSenderA())

이제 IOC 컨테이너 유틸리티인 Ninject가 개입할 시기다. Ninject 라이브러리를 참조하고 아래와 같이 코드를 수정한다

역시 잘 동작한다. 그러나 좀 더 유연하게 하고 싶다. 위 코드에서도 EmailSenderA가 슬그머니 한 자리를 차지하고 있다. 이것마저 제거하고 싶어 졌다. 즉 Config 파일에 구상객체 정보를 설정해서 보다 유연하게 만드는 것이다. 다음 주소에서 훌륭한 코드를 볼 수 있었다.

http://www.stum.de/2009/12/30/loading-a-type-specified-in-web-config-for-example-a-ninject-module/

먼저 실제 구상객체가 표현되는 Ninject 바인딩 부분을 NotificationAgent와 분리시킨다

* NinjectMoudleA

여기까지만 해도 꽤나 유연해진 모습이다. 필요시 Dll을 교체해서 환경 변화를 수용할 수 있다.

그러나 조금 더 나아가 Config에서 위 모듈을 동적으로 불러오도록 변경해 보자.

NotifcationAgent에 다음과 같이 KernelCreator라는 클래스를 생성한다. 이 클래스는 Config 파일로부터 (앞서 생성한) NoinectMoudle을 동적으로 불러들여서 Ninject 커널 객체를 반환한다.

Config 파일 설정은 다음과 같다.

* App.Config

이제 NotificationAgent는 다음과 같이 작성할 수 있다.

이제 변화에 유연하도록 구성이 완료되었다.

만일 환경이 달라저서 다른 이메일 전송 방법을 사용해야 한다면, 다시말해 NotifactionMethodB로 교체되어야 한다면 다음의 과정을 거치면 된다

1. MailService의 IEmailSender 인터페이스를 구현한다(NotifactionMethodB)

2. NinjectMoudleB를 생성해 Ninject 바인딩을 정의한다

3. Config 파일을 수정한다

이 과정이 복잡해 보일 수 있으나 모든 시스템 환경에 적용할 필요는 없을 것이다. 유연성 사치를 부릴 필요가 없는 시스템이라면 위의 전체 과정에서 몇 가지를 제거할 수도 있다. 위 과정은 이미 개발된 시스템의 변경을 최소화하고 확장을 유연하게 할 수 있도록 하는 만큼 시스템 환경에 따라 적절히 적용할 수 있을 것이다.

RSS 구독중인 어느 블로그에서 '나이 든 사람이 해야 할 33가지'라는 글을 보며, 이것은 비단 나인  든 사람에게만 해당되는 글이 아니라 젊은 사람에게도 해당되는 좋은 글이라 몇 가지 발췌해 본다

식상할 정도로 간단한 예기일 수 있지만, 매일 같이 즐거운 인생을 보내기 위한 핵심 원칙인 듯 하다.

우리 애들은 매주 일요일마다 한 시간 가량 컴퓨터 게임을 한다. 일요일에 컴퓨터 게임을 한다는 즐거운 일이 애들을 기쁘게 하듯이 어른들도 즐거운 일을 만들수 있지 않겠는가? 매일 반복되는 일상에서 사소한 어떤 이벤트 하나를 기다리는 즐거움을 다들 느껴봤을 것이다. 개인적으로 (사소하더라도) 즐거운 일을 하나씩 만드는 노력이 필요하다는 생각이 든다.

부모 자식간, 효자도 일일이 간섭하면 싫어하는데 다른 관계에서는 두 말할 나위 없을 것이다. 간섭으로 누군가를 바꿀 수 있다는 무모한 생각을 집어 치우도록 하자

그래.. 난 술,담배를 줄여야만 해!

남에게 대우 받으려고 애쓰는 시간에 자신에게 좀 더 솔직해지고 충실해 지는 것이 현명한 듯.

사람을 좋아하기 위한 기본 원칙이다. 잘못 보다는 그 만의 장점을 부각하여 생각의 초점을 맞추면 대부분의 사람이 괜찮아 보인다. 이것은 스스로를 위해 필요한 일이다.

보면서 피식하고 웃음이 나왔다. 그래.. 죽으면 욕 먹을 일도 없다. 욕 먹는 것 역시 살아 있고 팔딱거리며 살고 있는 증거인 셈이다. 재미있는 표현이다. ㅎㅎㅎ

좋은 글 출처: http://socialjob.egloos.com/5750770

“내가 아니면 누가 올바른 말을 해 주겠냐?”고 그들은 입버릇처럼 말한다.

이들은 자기들이 똑똑해서 남들이 보지 못하는 것을 찾아낸다고 생각한다. 그러나 이건 착각이다. 비판이라는 것은 지독히 악한 습관일 뿐이다. 비판이란 짜릿한 순간의 쾌감 외에는 아무것도 주지 않는다.

비판으로 무엇이 고쳐질 것이라는 기대는 하지 말라. 비판은 아무에게도 감동을 주지 못할뿐더러 아무것도, 아무 사람도 바꾸지 못한다. 온 세상이 비판하는 말쟁이들로만 채워진다면 어떻게 될까? 생각만 해도 끔찍한 일이다.

- 박요한 <여유 있는 삶을 위해 하루를 사는 지혜> -

비판... 그래 비판은 누구도 변화 시키지 못한다.

그들의 개선을 바라는 진심어린 충고가 아니라면, 비판 할 자격은 누구에게도 주어지지 않는다!!!

프로그램 코드의 주석은 코드 이해와 유지보수성을 좋게 하는 중요한 요소이다.

그러나 실무 환경에서는 잘 지켜지지 않는 경향이 있다. 개발 규칙이 철저하게 지켜지는 환경이라면 몰라도 그렇지 않을 경우 종종 무시되곤 한다.

코드에 주석을 다는 것이 중요하다는 것은 두말이 필요 없을 것이며, 더 나아가 주석에 어떤 내용을 담을 것인가도 매우 중요하다 하겠다. 특히 다른 사람이 작성한 방대한 코드를 분석하게 될 경우 주석의 퀄리티(?)는 분석을 얼마나 빨리 정확하게 하는가의 주요한 잣대가 된다.

주석의 퀄리티는 주석에 담긴 내용으로 평가할 수 있다. 개인적으로 주석의 내용은 다음과 같은 순으로 작성하는 것을 권장.. 아니 필수라고 하고 싶다.

지금 자신의 주석 습관을 되새겨 보자. 대체로 What 을 설명하고 있지 않는가?

제일 중요한 것은 Why이다. 즉 해당 코드가 왜 이렇게 작성되었는가?에 대한 대답이다. 특히 오랜 시간 유지보수되어온 코드라면 Why는 더욱 중요해진다. 대부분의 프로그램은 시간이 감에 따라 수정/보완이 되고, 요구사항/환경의 변화와 시스템의 제약사항 등으로 처음 보는 사람이 쉽게 납득하지 못하는 형태로 변모되기 일쑤다.

다시 말해 코드 자체가 이해 되지 않는 경우보다는 왜 코드를 이렇게 작성해야 했는가?... 에 대한 대답이 필요하게 되는 것이다. 이것은 코드를 잘 작성했고 못했고의 문제가 아니다. 코드의 히스토리에 대한 의문이다.

필자는 실제로 방대한 시스템을 인수받을 일이 있었다. 그 시스템은 오랜 시간 운영 되어온 시스템으로 주석이 잘 작성되어 있지 않았을 뿐더러 있는 주석의 경우에도 대부분 What를 설명하고 있었다. 따라서 코드 분석에 가장 많은 시간을 할애한 부분이 바로 Why에 대한 대답을 찾는 것이었다.

사실 코드를 읽을 수 있는 프로그래머라면 What과 How는 어렵지 않게 파악이 가능하다. 그러나 Why의 경우 쉽지 않다. 특히 코드 자체가 아니라 시스템의 제약사항이나 요구사항의 특수성을 반영한 코드를 Why 없이 분석한다는 것은 참으로! 쓸데 없는 에너지가 낭비되는 것이다.

(참고로 개발자 들이여... 남의 코드를 보고 무조건 까지 말자. 그에게 말 못할(?) Why가 있었을지도 모른다)

결론! What과 How도 간단하게 명시하는 것이 좋지만 귀찮다면 Why 라도 남기도록 하자.

혹시 '누구 좋으라고' 라는 의문이 드는가? 그렇다면 당신은 지친 개발자!

아침 출근길에 애매한 신호등과 마주쳤다.

빨간불이었다가, 갑자기 빨간등과 녹색등이 같이 들어와 버린 상황. 순간 정지해 있던 차량들의 주춤거리는 모습. 다행히 차량 통행이 많지 않고 복잡한 도로가 아니라서 큰 혼란은 발생하지 않았지만, 문득 머리속에 스친 생각은 프로젝트 관리도 이와 다르지 않다는 것이었다.

(당신이 이 신호등과 마주쳤다면 어떻게 하겠는가?)

프로젝트 관리자는 여러 애매한 상황에 놓인다. 특히 시스템이 방대하고 이해관계 마저 복잡한 경우에는 더욱 그러하다. 따라서 프로젝트 관리자는 애매한 상황을 정리하는데 노력을 기울여야 하며, 프로젝트 구성원들이 정확한 노선으로 일을 진행할 수 있도록 도와야 한다.

프로젝트 관리자가 어떤 결정을 내릴 때, 스스로 애매함을 정리하기 힘든 상황이라면 다음 두 가지 요령이 필요하다.

애매함 보다는 차라리 고집이 낫다

애매함을 오랜 시간 방치하기 보다는 차라리 고집을 부리는 것이 낫다. 오랜 시간 방치한 애매함은 프로젝트의 진행을 더디게 만들고 구성원들을 지치게 한다. 차라리 결정을 하고 독단적이라는 비난을 두려워 하지 말고 고집을 부리는 편이 낫다. 단, 고집을 부릴만큼 본인이 많은 고민을 해야 한다. 한면이라도 고집의 근거와 타당성이 있어야 한다는 말이다.

애매함 보다는 위임을 활용하라

고집을 부리기 싫거나 한면이라도 타당성을 찾기 힘든 상태, 아니면 그 어떤 이유로든 고집을 부리기 힘든 상황이라면 차라리 그 결정을 위임하는 것이 좋다. 이것은 책임을 회피하기 위해 일을 떠넘기는 개념과는 다르다. 결정도 정확히 내리지 않고 누군가가 결정하도록 위임도 하지 않는다면 모두가 실패하는 결과를 맞을 것이다. 수 많은 결정들 가운데 일부는 그들의 능력을 전적으로 활용하라는 것이다.

물론 고집과 위임이 애매함의 유일한 해결책은 아니다. 이것은 애매함을 순조롭게 풀기 힘든 상황에 꺼낼 수 있는 카드라고 하는 것이 맞겠다.

표준 인증체계를 정의하는 OAuth에 적용된 보안 개념들은 OAuth를 사용하지 않더라도 인터넷과 같은 열린 공간에서의 통신에서 보안을 강화하는 아키텍처로써 가치가 있다.

분산 시스템간 통신 시, 이러한 개념을 적절히 접목하면 보안성이 잘 갖춰진 시스템을 만들 수 있을 것이다.

먼저 시스템간의 통신에서 보안이란 대략 다음과 같은 요소들로 정리할 수 있겠다.

1. 기밀유지 (암호화)

보안의 가장 기본적인 요소로 데이터를 읽지 못하게 만들어야 한다.

공격자가 통신 패킷을 중간에 가로채서 보더라도 데이터를 읽을 수 없는 상태로 만들어야 하는데 이를 위해 각종 암호화 기법을 적용하게 된다.

2. 신원확인 (자격증명)

허가된 클라이언트만이 통신을 허용할 수 있도록 해야 하는데 이를 위해 클라이언트는 자신의 자격증명을 제출하도록 한다. 보통 ID/PW를 제출하기도 하고 클라이언트 인증서, 임의의 토근 등이 사용되기도 한다.

3. 변조 방지 (디지털서명)

공격자가 통신 패킷을 중간에 가로채서 변경하지 못하도록 해야 한다.

서버의 입장에서는 요청이 중간에 변조되지 않았는지를 확인 해야 하는데, 이를 위해 전송 데이터의 해시 값을 구하고 이 해시 값을 클라이언트의 비밀키로 암호화하도록 한다.

이를 디지털 서명이라고 하는데 변조 방지 뿐만 아니라 클라이언트가 자신이 보낸 것이 아니라고 하는 부인방지도 효과도 있다.

4. 재생 방지

일반적인 보안 시나리오에서 간과되기 쉬운 부분인데, 분산 환경에서의 통신에서는 특별히 주의해서 방어해야 하는 요소이다. 앞의 1,2,3 의 보안 요소들이 잘 갖춰져 있다하더라도 공격자가 중간에서 패킷을 가로채 그대로 다시 서버로 전송할 경우 이를 거부하도록 해야 한다.

OAuth 프로토콜은 이러한 보안 개념들을 적절히 잘 접목한 안전한 인증시스템이라 할 수 있다.

OAuth를 통한 인증 과정에서는 실제로 기밀유지보다는 변조방지와 재생방지에 무게 중심이 있다고 하겠다.

OAuth 인증 과정에서는 비밀번호라던가 주민번호와 같은 기밀을 유지해야 하는 민감한 데이터가 포함되지 않기 때문에 기밀유지를 위한 과도한 암호화는 불필요하다. 다만 인증된 클라이언트에 의한 유효한 요청인지가 더욱 중요하다는 것이다.

(OAuth 인증 과정 중, 사용자가 ID/PW를 입력해서 로그인 하는 과정이 있지만 이 부분은 OAuth 인증 과정이라기 보다는 사용자와 서비스 프로바이더간 보안 구간이라고 하겠다.

또한 OAuth 인증 과정을 모두 완료한 후 액세스 토큰으로 보호된 자원에 접근하는 경우에 기밀 데이터가 있을 경우 htts와 같은 별도의 암호화 장치를 둬야 한다. 이 구간 역시 OAuth 인증 과정과는 별도로 이해하기 바란다)

OAuth에서는 데이터의 변조 방지를 위해 해시 값과 디지털 서명을 사용한다.

이때 Consumer Secret 이 비밀키로 사용되며 HMAC-SHA1와 같은 해싱 알고리즘이 적용된다.

(참고로 OAuth 2.0의 경우, HTTPS를 사용하게 됨으로써 HAMC를 사용하지 않아도 된다)

그리고 재생 방지를 위해서는 Timestamp와 Nonce가 사용되는데,

Nonce는 모든 요청에 유일함이 보장되어야 하는 (클라이언트에서 생성하는) 임의의 문자열인데,

재생 공격시 이 값을 체크해서 (이미 이전 요청에 사용된 Nonce일 경우) 요청을 거부하게 된다.

그렇다면 Nonce의 유일성을 체크해야 하는 서버의 입장에서는 모든 요청의 Nonce 값을 보관하고 있어야 하는 부담이 있는데, 이는 Timestamp 체크로 부담을 제거하게 된다.

OAuth 인증 과정에서 포함되는 Timestamp는 요청을 생성한 시점의 타임스탬프 값으로써 1970년 1월 1일 00:00:00(GMT) 이후의 시간을 초로 환산한 숫자 값인데 이 값의 유효 범위를 지정해 기간이 경과한 요청은 거부하도록 한다.

즉 Nonce의 유일성 체크 이전에 Timestamp에 의한 유효 시간 체크를 먼저 함으로써 서버 입장에서는 유효시간 내의 Nonce값만을 관리하면 되는 것이다.

마지막으로 OAuth 인증 과정을 모두 마치면 클라이언트는 사용자의 인증을 대신하게 되는데 이때 Authorization Header라는 HTTP 헤더 값을 자격증명으로 제출하게 되는 셈이다.

이러한 OAuth 인증과정에 적용된 보안 개념들은 다른 어플리케이션을 개발할 때에도 참고하기에 충분한 가치가 있다고 하겠다.

다음 문제를 풀어 보자.

문제를 쉽게 풀었다면 패스~~

Enum을 정의할 때 FlagAttribute를 적용하면, 열거형 값들을 조합해서 사용할 수 있다.

예를 들어 File과 Database 두 값 모두 라는 의미로 다음과 같은 코드 사용이 가능하다

LogType logType = LogType.File | LogType.Database

...

bool isFile = (myType & LogType.File) == LogType.File;

FlagAttribute는 Enum을 BIT Flag 처리가 가능하도록 설정하는 것이다.

BIT Flag의 동작 방식을 이해하고 있었다면, 문제를 쉽게 풀었을 것이다.

열거자 목록에 사용된 값들의 bit가 켜고 끄는 형태 즉, On/Off 형태가 되도록 구성해야 한다.

그래야 bit의 OR / AND 연산이 제대로 동작하게 되는 것이다.

다시 말해, 각 값들의 비트 구성이 다음과 같도록 구성해야 한다.

따라서 정답은 다음과 같다.

이제 다음 코드의 의미를 다시 보면,

LogType logType = LogType.File | LogType.Database

정수 1과 2(비트 1과 10)의 비트를 (OR 연산으로) 모두 ON 상태로 만드는 것이다.

그리고 다음 연산으로 자신의 비트만 켤수 있도록 비교하게 된다.

(myType & LogType.File) == LogType.File

----------------------------------------------------------------------------------------

여기서 좀 더 세련된 코딩을 하자 치면...

이러한 비트 구성은 2의 제곱형태가 되는 걸 알 수 있다.

즉 비트가 왼쪽으로 한 칸씩 쉬프트되는 구조 이므로 다음과 같이 코딩할 수 있겠다

-------------------------------------------------------------------------------------

마지막으로 전체 선택은 비트를 모두 켠(ON) 것이고,

그 반대는 비트를 모두 끈(OFF)한 것이므로 다음과 같이 코딩하면 된다.

열거자 값이 많고 계속 늘어날 수 있는 경우 모든 비트가 켜진 정수의 최대값을 지정해되 된다.

All = Int32.MaxValue

WCF 서비스의 보안 모드를 Message 보안으로 하고 클라이언트 자격증명 타입을 UserName으로 한 후,

테스트 X.509 인증서를 생성해서 자격 증명, 암호화, 디지털 서명 등이 잘 되는지 확인을 완료했다.

그리고 알파 서버로 서비스를 셋팅하고 테스트를 해 보니 보안 예외가 계속 발생한다.

이벤트 로그를 보면 다음과 같은 로그가 남겨져 있다.

개발 PC에 서비스와 클라이언트를 모두 구동할 때는 발생하지 않던 것이, 서버를 옮긴 후 발생하는 것이다.

서버와 클라이언트 PC의 시간차에 의한 보안 예외가 발생한 것이다.

즉 메시지가 생성된 시점의 타임스탬프의 유효기간을 체크함으로써 재 전송 공격(Replay Attacks)을 방지하기 위한 보안 메커니즘에 위배된다는 것이다.

그런데 이 보안 매커니즘이 대략 난감한 상황이 될 수도 있다.

클라이언트와 서버의 시간이 어쩔 수 없이(?) 다를 수 밖에 없는 환경이거나 안정적인 타임 서버 기반으로 시간 동기화를 하지 못하는 경우에 어느 시점에 시간 차가 날지 예측할 수 없기 때문이다.

기본 보안 설정에서는 두 서버의 허용 시간 차가 5분이다.

서버와 클라이언트 시간을 동기화 해 주지 않는 이상 5분 이라는 최대 허용 시간을 늘릴 수 밖에 없는데...

문제는, 이 것이 간단히 속성 값 변경으로 될 수 없다는 것이다.

WCF의 커스텀 바인딩을 통해 최대 허용 시간을 변경할 수 있다고 하니, 대략 귀찮아 지게 생겼다.

http://msdn.microsoft.com/en-us/library/ms733063.aspx

http://www.danrigsby.com/blog/index.php/2008/08/26/changing-the-default-clock-skew-in-wcf/

http://msdn.microsoft.com/en-us/library/aa738468.aspx