Korea Evangelist

Developer & Platform Evangelism, Microsoft Korea

August, 2010

  • Korea Evangelist

    (6) Razor 강좌 - 레이아웃 페이지 구조 처리

    • 0 Comments

    안녕하세요. 김대우 입니다.

    코난이와 함께하는 Razor & WebMatrix 시리즈 강좌리스트

    (1) WebMatrix와 Razor! 이제 시작합니다.

    (2) WebMatrix 설치부터 Hello World까지

    (3) Razor 강좌 - 기본 구문 및 주석 처리

    (4) Razor 강좌 - 코드 블록과 POST 처리

    (5) Razor 강좌 - 재사용 가능한 코드 생성

    (6) Razor 강좌 - 레이아웃 페이지 구조 처리 - (지금 보고 계신 내용)

    (7) Razor 강좌 - 파일처리

    (8) Razor 강좌 - 데이터베이스 처리

    (9) Razor 강좌 - Helper 소개(이미지, 비디오)

    (10) Razor 강좌 - 디버깅

    (11) Razor 강좌 - 캐시 처리

    지난 시간에는 “(5) Razor 강좌 - 재사용 가능한 코드 생성” 강좌를 진행 했습니다.

    이번 시간에는 바로 이어서 여섯번째 강좌, “Razor 강좌 - 레이아웃 페이지 구조 처리” 강좌를 진행 하도록 하겠습니다.
    이 녀석도 실제 구조만 이해하시면 어렵지 않은 내용이에요. 꼬옥 아래 처음으로 보여 드리는 처리 구조를 잘 살펴 보시고 이해하시면 아래의 내용은 모두 껌처럼 보이실 겁니다.
    왜 Layout을 이용하는가?
    이전 강좌에서는 RenderPage를 이용해 페이지의 특정 위치에 원하는 내용을 삽입하는 처리를 진행해 보았습니다. 하지만, 개발자의 입장에서 볼 때, 재사용성을 극대화하고 좀더 구조적으로 페이지의 디자인과 레이아웃을 살릴 수 있는 과정이 필요하게 됩니다. 이 경우에 이용 가능한 처리가 바로 레이아웃 페이지(Layout page) 방식입니다. 먼저 아래 그림을 통해 처리 방식을 반드시 먼저 이해 하시는 게 아주 중요합니다.
    layout

    처리 방식은 이렇습니다. 꼭 이해하셔야 아래 나머지 강좌 내용이 수월 하실 거에요.
    1) 사용자가 Content Page를 요청합니다.
    2) Content Page는 레이아웃 페이지의 링크를 담고 있습니다.
    3) 레이아웃 페이지가 호출되며 레이아웃 페이지 내부에서 Content Page가 렌더링 됩니다.
    4) 레이아웃 페이지에서 다른 페이지 역시 호출해(include) 재사용 가능합니다.
    5) 사용자에게 모든 렌더링된 레이아웃 페이지가 전달됩니다.
    어떠세요? 조금 감이 잡히시는지요?
    레이아웃 페이지는 마치 HTML 파일처럼 콘텐트 정보를 제외한 모든 처리를 넣을 수 있습니다.

    HTML페이지와 다른점은 오직 콘텐트 페이지의 정보를 담기 위한 RenderBody나 RenderPage가 호출된다는 점 뿐이지요.
    몇 가지 더 경험적인 Tip을 말씀 드리자면, 앞의 강좌의 재사용을 위한 RenderPage 방식보다 이런 레이아웃 방식을 대규모의, 디자인과 협업이 더 많이 필요할 경우에 주로 사용하게 됩니다. 정보와 디자인을 쉽게 분리해 개발자와 디자이너간 협업을 증대시키며 구조적으로 정보를 개발자의 조건에 따라 레이아웃 페이지에 삽입 여부 등도 제어가 가능하기 때문에 더욱 동적이고 개발자와 디자이너 협업이 가능한 처리를 이용 가능하기 때문입니다.
    자, 이제 처리 방식이 조금 이해 되셨다면, 저와 같이 코드를 직접 실행해 보시지요.
    앞의 강좌에서 “Reuse”라는 폴더를 만들어 두었습니다. 아래처럼 파일들을 이 폴더에 생성해 볼께요.

    <!DOCTYPE html> 
      <head> 
        <title> 레이아웃 콘텐트를 만들어요 </title> 
        <link href="@Href("Styles/Site.css")" rel="stylesheet" type="text/css" /> 
      </head> 
      <body> 
        @RenderPage("_Header2.cshtml") 
        <div id="main"> 
          @RenderBody() 
        </div> 
        <div id="footer"> 
          &copy; 2010 SQLER의 Razor와 WebMatrix 강좌. 
        </div> 
      </body> 
    </html>

    “_layout1.cshtml” 파일로 저장합니다.


    @{ 
        LayoutPage = "_Layout1.cshtml"; 

    <h1> 구조화된 콘텐트  </h1> 
    <p>

    택시기사가 나를 보통 녀석이 아닌데?라고 생각하게 만드는 방법 (1/3)

    1 왼쪽 문을 열고 타자마자 오른쪽 문을 열고 내린다.
    4 요금이 오를 때마다 비명을 지른다.
    7 어느새 내가 운전한다.
    18 U턴 해서 반대 차선에 내려 주세요.
    21 택시에 타자마자 페브리즈를 마구 뿌린다.
    28 재개발 지구나 새 건물이 들어 선 거리를 지날 때 한숨을 쉬며 「하나도 안 변했네··· 여기」라고 중얼거린다.
    번역 : 행복한 마조히스트(sweetpjy.tistory.com)
    <p>

    “Content1.cshtml” 파일로 저장합니다.

    <div id="header">  
      구조화된 콘텐트를 만들어 보세요~

    </div>

    “_header2.cshtml” 파일로 저장합니다.

    Reuse 폴더 하위에 “Styles” 폴더를 만들어 주세요.

    h1 { 
        border-bottom: 3px solid #cc9900; 
        font: 2.75em/1.75em Georgia, serif; 
        color: #996600; 

    ul { 
        list-style-type: none; 

    body { 
        margin: 0; 
        padding: 1em; 
        background-color: #ffffff; 
        font: 75%/1.75em "Trebuchet MS", Verdana, sans-serif; 
        color: #006600; 

    #list { 
        margin: 1em 0 7em -3em; 
        padding: 1em 0 0 0; 
        background-color: #ffffff; 
        color: #996600; 
        width: 25%; 
        float: left; 

    #header, #footer { 
        margin: 0; 
        padding: 0; 
        color: #996600; 
    }

    이 파일은 Styles 폴더 하위에 “Site.css” 파일로 만들어 주세요.

    이제 실행을 해 볼까요? WebMatrix에서 Content1.cshtml을 선택하시고 F12를 눌러 실행해 주세요.
    조금 파일들이 많으시지요? 걱정 마세요. 이해만 하시면 아주 쉽습니다.

    이 강좌 맨 위의 처리 흐름을 생각 하시면서 설명 드릴께요.
    1) 사용자의 요청으로 Content1.cshtml 파일이 실행되면 Layout1.cshtml 페이지를 호출합니다.
    2) Layout 페이지에서 Header 영역을 불러와 include 시키고 바로 아래에서 Content 페이지의 내용을 RenderBody로 호출합니다.
    3) 만들어진 콘텐트가 담긴 레이아웃 페이지가 사용자에게 CSS 디자인 파일과 함께 전달됩니다.
    콘텐트 페이지의 특정 영역을 레이아웃 페이지 특정 영역에 표시

    쿨럭. 쓰고 나니 제목이 더 복잡하네요. 의도한 바는 아닙니다만, 아래 도표를 보시면 바로 감이 오실 겁니다. 먼저, 아래 도표를 보시지요.
    layout2

    1) 사용자의 요청이 콘텐트 페이지에 도착하면 레이아웃 페이지가 호출됩니다.
    2) 레이아웃 페이지의 RenderSection은 콘텐트 페이지의 지정된 Section을 쏙쏙 가져와 표시합니다.
    3) RenderBody와 혼용도 가능합니다.
    4) 사용자에게 콘텐트가 입혀진 레이아웃 페이지가 전달됩니다.
    자 그럼 마찬가지로, 예제를 통해 이해해 보도록 하겠습니다.

    <!DOCTYPE html> 
    <html> 
        <head>
          <title>섹션이 존재하는 콘텐트 파일</title> 
          <link href="@Href("Styles/Site.css")" rel="stylesheet" type="text/css" /> 
        </head> 
        <body> 
          <div id="header"> 
            @RenderSection("header")
          </div> 
          <div id="list"> 
            @RenderSection("list") 
          </div> 
          <div id="main"> 
            @RenderBody() 
          </div> 
          <div id="footer"> 
            &copy; 2010 SQLER의 Razor와 WebMatrix 강좌 
          </div> 
        </body> 
    </html>

    ”_Layout2.cshtml” 파일로 저장합니다.

    @{  
        LayoutPage = "_Layout2.cshtml"; 

       @section list { 
        <ul> 
            <li>김대우</li> 
            <li>박중석</li> 
            <li>황리건</li> 
            <li>조성우</li> 
            <li>김영욱</li> 
            <li>김재우</li> 
            <li>서진호</li> 
        </ul> 

    @section header { 
        <div id="header">  
            레이아웃 페이지 제작 
        </div> 

    <h1>여러개의 섹션이 있는 콘텐트</h1> 
    <p>

    택시기사가 나를 보통 녀석이 아닌데?라고 생각하게 만드는 방법 (2/3)

    39 내릴 때 레드 카펫을 깐다.
    45 비 내리는 밤에 택시를 타고 「저기, 요즘에 이 근처에서 뭐가 나온다는 소문이 돌잖아요~」
    49 「오늘은 여기에 한 번 둬 볼까……… 」 라고 말하며 계기판 위에 물이 든 종이컵을 내려놓는다.
    59 행선지를 물어보면「몰라요···!!」하고 운다.
    70 들고 있던 비상등을 차 위에 올리고「빨리 갑시다, 신호는 무시하세요!」
    95 차멀미가 심하니까 잘 부탁드려요. 이러면 운전을 정말 조심스럽게 해준다.
    99 타자마자 「교통 불편 신고 엽서」를 집어 든다.
    104 땀을 뻘뻘 흘리면서 항문을 손으로 틀어막고 조심조심 탄다.
    번역 : 행복한 마조히스트(sweetpjy.tistory.com)
    </p>

    ”Content2.cshtml” 파일로 저장합니다.

    보시는 것처럼, 레이아웃 페이지에서 RenderSection을 통해 영역을 구별해 두게 됩니다.

    이어서 콘텐트 페이지에서 @section 을 이용해 콘텐트를 분리해 처리하게 되지요.
    그럼, WebMatrix에서 Content2.cshtml 파일을 선택하시고 F12를 눌러 실행해 보세요.
    레이아웃 페이지는 구조와 영역에 대한 처리가 사실상 전부 입니다. 잊지 마시고, 꼭 페이지가 어떻게 렌더링 되어 사용자에게 표시되는지, 그 흐름을 고민하면서 진행해 보시길 바랍니다.
    Section이 존재하지 않을 경우 처리
    위의 콘텐트 페이지에 각 Section 정보를 담고 있습니다. 레이아웃 페이지에는 이 Section을 표시하라고 명시되어 있는데, 몇몇 콘텐트 페이지만 이런 Section이 빠져 있다면 어떻게 될까요? – Section 여부에 따른 분기 처리가 가능합니다. 아래 내용을 참고 하세요.
    Content2.cshtml 페이지에서 아래 섹션을 제거해 보세요.

    @section header { 
        <div id="header">  
            레이아웃 페이지 제작  
        </div> 

    네, 바로 header 섹션을 없애 버리는 겁니다. 저장 하시고, Content2.cshtml 파일을 WebMatrix에서 실행해 보시면. 뚜시꿍~ 에러가 떨어집니다.
    layout3
    이럴 경우를 위해 간단히 Layout 페이지를 살짝 손보면 됩니다.

    _Layout2.cshtml 파일을 열고

        @RenderSection("header")

    항목을 아래로 변경합니다.
    @RenderSection("header", optional: true)
    또는, 아래처럼 if 분기로도 처리가 가능합니다.

    @if (IsSectionDefined("header") {
        @RenderSection("header")
    }

    Section이 없더라도 걱정하실 필요 없지요? ^_^

    끝으로, 데이터를 레이아웃 페이지로 넘기는 방법에 대해서 말씀 드리도록 하겠습니다.
    콘텐트 페이지의 데이터를 레이아웃 페이지로 전달
    콘텐트 페이지에서 사용자의 로그인 상태를 레이아웃 페이지에 전달해 그에 맞게 페이지를 렌더링 하고자 할 경우에 반드시 콘텐트 페이지에서 데이터를 레이아웃 페이지에 전달해 적절한 처리가 이루어지도록 구성할 필요가 있습니다. 이럴 경우를 생각해 보시면 좋을 거에요. 어렵지 않습니다. 이럴 경우 값을 전달할 경우에는 Request 처리와 비슷하게 “PageData” 속성을 이용하시면 됩니다.
    예제를 돌려 보도록 할께요.
    흐름은 간단히, PageData 조건을 검사해 메뉴 아이템들을 표시할지 말지 여부를 결정하는 간단한 예제라고 보시면 됩니다.

    @{  
        LayoutPage = "_Layout3.cshtml"; 
        PageData["Title"] = "데이터 전달"; 
        PageData["ShowList"] = true; 

        if (IsPost) { 
            if (Request["list"] == "off") { 
                PageData["ShowList"] = false; 
            } 
        } 

    @section header { 
        <div id="header">  
            레이아웃 페이지 만들기  
        </div> 

    <h1>@PageData["Title"]</h1> 
    <p>

    택시기사가 나를 보통 녀석이 아닌데?라고 생각하게 만드는 방법 (3/3)

    106 룸미러 너머로 운전기사의 얼굴을 심각하게 응시.
    135 혼자 탄 다음에 아무도 없는 조수석 쪽에 계속 말을 건다.
    144 조수석 앞에 붙은 기사증을 소리 내서 읽는다.
    157 경찰차가 지나가면 몸을 숙인다.
    161 준비한 애니메이션 CD를 카오디오에 넣고 튼다.
    172 뒷자석으로 타서 조수석으로 옮겨 앉는다.
    223 타자마자 「트렁크가 열려있는데요? 」 한다. 운전기사가 확인하러 간 사이에 운전석에 앉는다. 그대로 출발.
    번역 : 행복한 마조히스트(sweetpjy.tistory.com)

    </p> 
    @if (PageData["ShowList"] == true) { 
        <form method="post" action=""> 
          <input type="hidden" name="list" value="off" /> 
          <input type="submit" value="Hide List" /> 
        </form> 

    else { 
        <form method="post" action=""> 
          <input type="hidden" name="list" value="on" /> 
          <input type="submit" value="Show List" /> 
        </form> 

    <br />

    Content3.cshtml 파일로 저장합니다.

    <!DOCTYPE html> 
    <html> 
        <head> 
          <title>@PageData["Title"]</title> 
          <link href="@Href("Styles/Site.css")" rel="stylesheet" type="text/css" /> 
        </head> 
        <body> 
          <div id="header"> 
            @RenderSection("header") 
          </div> 
          @if (PageData["ShowList"] == true) { 
              <div id="list"> 
                @RenderPage("/Reuse/_List.cshtml") 
              </div> 
          } 
          <div id="main"> 
            @RenderBody() 
          </div> 
          <div id="footer"> 
            &copy; 2010 SQLER의 Razor와 WebMatrix 강좌  
          </div> 
        </body> 
    </html>

    ”_Layout3.cshtml” 파일로 저장합니다.

    <ul> 
            <li>김대우</li> 
            <li>박중석</li> 
            <li>황리건</li> 
            <li>조성우</li> 
            <li>김영욱</li> 
            <li>김재우</li> 
            <li>서진호</li> 
    </ul>

    _List.cshtml 파일로 저장합니다.

    흐름은 간단히, PageData 조건을 검사해 메뉴 아이템들을 표시할지 말지 여부를 결정하는 예제라고 보시면 됩니다.
    완료 하셨다면, Content3.cshtml 파일을 실행해 보세요. 아래의 “Hide List” 버튼을 클릭하시면 Post 여부에 따라 넘겨받은 PageData로 레이아웃이 변화합니다.

    어떠세요? 어렵지 않으시지요?
    자~ 이렇게 해서 지난 시간의 RenderPage에 이어 레이아웃을 이용한 처리 역시 알아 보았습니다.

    사실, 맨 처음에 말씀 드린 것처럼,  콘텐트 페이지와 레이아웃 페이지가 어떻게 서로 지지고 볶으면서 영역들을 렌더링 하는지 여부만 이해하시면 조금은 쉬운 내용셨을 거라고 생각되네요.
    레이아웃 처리를 이용할 경우는...
    1) 개발자의 입장에서 레이아웃의 재사용성을 극대화하고
    2) 디자이너와 협업을 통해 구조적으로 페이지의 디자인과 레이아웃을 살릴 수 있는 과정이며
    3) 레이아웃과 콘텐츠 페이지간 데이터 전달 및 상호작용이 가능한 처리 방식입니다.
    자~ 그럼 레이아웃 강좌를 마무리 하도록 하겠습니다.
    다음 강좌인 "(7) Razor 강좌 - 파일처리" 에서 뵙도록 하겠습니다. ^_^
    감사합니다.~
    PS.
    cshtml 파일 앞에 “_”가 붙은 녀석은 사용자의 요청에 의해 실행 불가한 파일입니다. 다른 콘텐트 페이지 같은 “_”가 없는 녀석들에 의해 참조되어 호출만 가능한 녀석이지요. 레이아웃 페이지나 항상 참조 되는 header, footer 페이지에 쓰면 유용하겠지요? 참고 하시길 바랍니다.

    참고자료 :

    (1) WebMatrix와 Razor! 이제 시작합니다.
    (2) WebMatrix 설치부터 Hello World까지
    (3) Razor 강좌 - 기본 구문 및 주석 처리
    (4) Razor 강좌 - 코드 블록과 POST 처리
    (5) Razor 강좌 - 재사용 가능한 코드 생성
    [동영상 강좌] (1) WebMatrix 첫 실행 & Hello World까지 달려요~
    [동영상 강좌] (2) WebMatrix 5분 리뷰~
    [동영상 강좌] (3) Razor 강좌 - 기본 구문 및 주석 처리
    [동영상 강좌] (4) Razor 강좌 - 코드 블록과 POST 처리
    ASP.NET 사이트의 Razor Tutorial 내용 3 - Creating a Consistent Look

  • Korea Evangelist

    [Code Party]8월 18일 세미나 예고편 공개!!

    • 0 Comments


    월간마소와 Microsoft 앞으로 1년간 매달 2회씩 진행하게 되는 개발자 세미나 코드 파티!!
    그 첫번째 세미나가 2010년 8월 18일 열림니다.

    자세한 세션 내용과 등록은 아래를 참조해 주세요 ^^
    http://www.youngwook.com/405

    개발자를 위한 IT블로그 영욱닷컴(http://www.YoungWook.com)

  • Korea Evangelist

    [아키텍처 저널 번역] 16권 클레임과 아이덴티티 #2/2

    • 0 Comments

    AJ16_cover

    지난 포스팅에 이어 아키텍처 저널 16권에 실린 사용자 인증 및 아이덴티티 관련된 아티클 번역물 두번째를 올린다. 클라우드가 ���제는 모든 비지니스의 기본 인프라처럼 여겨지는 시대가 되어 가는데, 이때 필요한 것이 상호간 Seamless 연동을 가능케하는 인증 체계의 통합이다. 이 글은 클레임 기반 인증 방식의 가장 기본이 되는 원칙과 원리를 설명하고 있으며, 이를 통해 클라우드 시대까지 확장할 수 있는 인증 통합을 살며시 이야기하고 있다. 

    이 아티클의 원문은 아래에서 확인할 수 있다.
    http://msdn.microsoft.com/ko-kr/architecture/cc836390(en-us).aspx

    참고로, 현재까지 번역된 아키텍처 저널은 다음과 같으며 3개의 아티클이 한글 PDF 버전으로 다운로드 가능하다.
    아키텍처 저널 21 : http://msdn.microsoft.com/ko-kr/architecture/aa699437.aspx
    아키텍처 저널 19 : http://msdn.microsoft.com/ko-kr/architecture/aa699428.aspx

    ---------------------------------------------------------------------------------------
    클레임 인식 솔루션의 아키텍처 패턴
    앞서 언급한 기본 개념은 새로운 인증 메커니즘의 기반이 된다. 따라서 이러한 개념을 조합하면 어떤 시스템과 트랜잭션도 설명할 수 있다. 이 새로운 세상에서, 전통적으로 하나로 융합되어 있던 두 가지 기능, 즉 (클레임을 통해) 호출자에 대한 정보를 얻는 기능과 (자격 증명을 통해) 호출자가 기존 사용자인지 여부를 확인하는 기능을 마침내 분리할 수 있게 되었다. 이러한 분리 덕분에 이제 어떤 기능이 시나리오에 가장 적합한지 결정할 수 있다(보다 자세한 내용은 리소스 부분 참조: Vittorio Bertocci의 블로그, The TAO of Authentication).
    일반적인 시나리오를 설명하는 데 특히 유용한 특정 패턴이 있으며, 이중 가장 일반적인 세 가지 패턴을 기술할 예정이다. 아울러 일반적인 시나리오에 대해서 클레임 기반 접근법이 기존 방식에 비해 갖는 장점을 몇 가지 설명할 예정이다. 모든 패턴은 온프레미스 및 클라우드 아키텍처 모두에 적합하다.

    정식 패턴: 주체(Subject)-IP-RP
    이 패턴은 인증 관리에 있어 드물게 발생하는 상황, 즉 하나의 주체가 제한된 리소스(RP)에 접근하길 원하는 상황을 설명한다. 이러한 패턴은 Windows 사용자가 네트워크 공유에 접근을 시도하는 경우, 스마트 클라이언트가 보안 웹 서비스를 호출하는 경우, 웹 서퍼가 제한된 컨텐츠를 찾아보는 경우 등에 발생한다(그림 2 참조). 주요 절차는 다음과 같다.

    그림 2. 주체-IP-RP 정식 패턴. 숫자는 텍스트를 나타낸다.

    1. (독립적으로) RP가 정책의 형태로 요구 사항을 게시한다. 이러한 요구 사항은 다음을 포함한다.
      1. 클레임 목록
      2. RP가 이러한 클레임의 소스로 신뢰하는 IP
      3. RP가 사용할 수 있는 특정 인증 기술에 관한 세부 정보 (예: RP가 이해하는 토큰 형식)
    2. 주체(Subject)가 RP 정책을 읽고 이를 준수할 수 있는지 확인한다. 이것은 실제로 주체가 RP가 신뢰하는 그 어떤 IP로부터도 적절한 토큰을 확보할 수 있는지 여부를 확인하는 것을 의미한다.
    3. 주체가 적절한 IP를 호출하고, RP 정책을 준수하는 토큰을 요청한다. 실제로 이는 일반적으로 RST 메시지를 IP의 STS로 전송하는 것을 의미한다.
    4. IP가 RST를 수신하고 주체를 인증한다. 주체가 확인되면 IP는 필요한 클레임 값을 검색하고, 토큰으로 패키지화하여, 서명 후 주체에 다시 전송한다.
    5. 주체는 이 토큰을 수신하여 RP를 호출하는 데 사용한다.
    6. RP가 호출 메시지에서 토큰을 추출한 후, 신뢰할 수 있는 IP에 의해 서명된 것인지와 적절한 클레임을 포함하고 있는지를 검사한다. 확인 결과가 긍정적이면,
      1. 클레임 값은 일부 접근 제어 로직을 공급하는 데 사용된다.
      2. 접근 제어 로직이 충족되면, 리소스 자체에서 클레임 값을 사용할 수 있게 되고, 접근이 허용된다.

    본 설명의 취지에 따라 여기서는 리소스가 웹 서비스라고 가정하도록 한다. 위의 패턴은 다수의 좋은 속성을 보여준다.

    인증 외부화 (Authentication externalization)
    토큰 및 클레임을 사용하면 리소스가 명시적 아이덴티티 관리 코드를 작성해야 하는 부담이 줄어든다. 또한, RP 정책 게시를 처리하는 인프라와 동일한 인프라가 토큰을 역직렬화하고, 서명을 확인하며, 리소스 개발자가 실제 사용되는 토큰의 형태에 관계없이 클레임 값을 손쉽게 사용할 수 있도록 하는 등의 작업을 수행할 수 있다. 이 인프라는 클레임 값에 기반해 일부 권한 부여를 결정할 수도 있어, 개발자의 작업을 더 줄여준다.
    이는 모든 시나리오에 적용되는 장점이지만, 호스팅 기술이 하나의 변수인 클라우드에서 특히 진가를 발휘한다. 클레임을 사용하면 리소스를 호스팅하는 인프라의 세부 정보와 런타임 시 제공되는 인증 기술 세부 정보로부터 리소스를 분리시킴으로써 진정으로 이식 가능한 리소스를 실현한다.

    리소스 레벨 정책 (Resource-level policy)
    리소스 레벨에서 정책을 지정할 수 있게 되면, 배포가 매우 민첩해지고, 상세한 제어가 가능하며, 인증 기술에 대한 선택을 동적으로 가능하게 한다. 또한, 상호 운용이 가능한 표준을 사용하기 때문에 호스팅 환경에 관계없이 효과적인 관리 전략을 수립할 수 있으며, 실행 환경으로부터 리소스 자체가 분리되기 때문에 (클라우드로의 이동 포함해) 리소스를 훨씬 더 쉽게 이동시킬 수 있다.

    자율성
    모든 리소스는 자율적으로 자신의 요구 사항을 명시하고, 주체(Subject)가 그러한 요구 사항을 자신의 능력과 매칭시킨다. 이와 같은 상호 작용은 리소스와 주체가 결합할 때 나타나는 특징적인 속성이다. 리소스와 주체 양쪽 모두 독립적으로 변할 수 있고, 리소스에 접근할 수 있는 주체들의 집합은 외부적인 영향이나 인프라 의존 관계와는 상관없이 리소스의 요구 사항을 준수할 수 있는 능력에 의해서만 정의된다. 이 시스템은 각자의 요구 사항 및 능력에만 신경 쓰면 되기 때문에 매우 강력하다. 명시적인 협상이나 조정이 필요하지 않으므로 사용자 참여도 매우 쉽다.

    일부 인증 및 권한 부여 로직의 중앙 집중화
    이 패턴에서는 IP가 모든 특성(attribute) 검색 작업을 수행한다. RP는 다른 시스템에 쿼리를 실행하지 않고도 필요한 것을 토큰 형태로 받는다. 이는 RP가 접근 권한을 가지지 않는 특성에는 분명 이점이 된다. (즉, 항공사 A가 주체의 파트너 항공사 B의 마일리지 정보를 요청하는 것과 같은 이치이다.) 뿐만 아니라 특성 검색 로직을 한 곳으로 중앙 집중화할 수 있는 훌륭한 수단이 된다. 또한, 특성 저장소에 접근해야 하는 접점(endpoint)의 수를 줄이고, 관리 용이성 및 보안을 향상시켜 준다. 뿐만 아니라, 일단 주체가 토큰을 얻으면 만료될 때까지는 IP에 조회할 필요 없이 이를 캐시 및 재사용할 수 있기 때문에 접근 횟수 자체도 줄일 수 있다. 또한, IP는 권한 부여를 결정하는 데 사용될 수 있는데, 이는 클레임을 통해서도 표현할 수 있다. 단, 이 때 IP는 주체 및 리소스 모두와 긴밀한 관계를 가지고 있어야만 한다. 이러한 패턴은 예를 들어 IP가 디렉터리를 나타내고 RP는 IP가 관리하는 리소스 중 하나인 경우와 같이 중요한 시나리오에서 발생하지만, 일반적으로 RP와 IP 사이에는 어떠한 관계도 가정될 수 없다.
    이것은, 가능한 사용자에 대한 정보를 확인하기 위해 리소스가 외부 IP에 의존해야 하는 경우와 같이 많은 클라우드 시나리오에 있어 핵심이 된다. 또한, 파트너 조직의 사용자가 기술이나 플랫폼과 무관한 토큰 형태로 표현될 수 있는, 전통적인 페더레이션보다는 다소 애자일한 경우에 아주 유용하며, 아울러 모든 유형의 경계를 넘나드는 경우에 큰 도움이 된다.

    클레임 변환기 유형: 주체-IP-클레임 변환기-RP
    방금 설명한 패턴은 일반 소비자(항공사 A의 단골 고객이 파트너 항공사 B의 웹 사이트를 접근하는 경우)에서 기업(거의 모든 Kerberos 시나리오가 그와 같은 방식으로 모델링될 수 있으며, 기술 독립성이라는 이점도 추가로 누릴 수 있음)에 이르기까지 광범위한 시나리오에 적용될 수 있다.
    단, 실제로는 특정 제약 조건으로 인해 이 패턴을 적용하지 못하는 상황이 존재한다.

    1. 간접 신뢰(Indirect trust). RP가 주체와 관계를 맺고 있는 IP를 직접적으로 신뢰하지 않을 수 있지만, 신뢰 관계를 중개해 줄 수 있는 일련의 중간 단계 인증 기관을 둘 수 있다. 비행기를 타고 싶다고 해서 지갑 속에 들어있는 신분 증명 문서(정부가 발행한 여권 또는 운전 면허증)만으로는 바로 비행기를 탈 수 없다. 탑승 게이트의 직원은 제대로 된 항공사에서 발급한 탑승권만 신뢰할 것이다. 따라서, 이미 소유하고 있는 신분 증명 문서를 체크인 프런트에서 사용하여 탑승권을 받으면 된다.

    2. 클레임 형식. 주체가 바로 이용할 수 있는 IP에서 발급한 클레임의 형식을 RP가 이해하지 못할 수 있다. 이는 때로는 단순한 형식 문제일 수도 있고 (예를 들어, 이탈리아 ID에 “birth date” 대신 “nato il”로 되어 있다면, 미국의 바텐더는 필요한 정보를 눈 앞에 두고도 알지 못한다.), 때로는 RP가 요구하는 클레임이 수신된 원시 정보를 가공한 결과를 원하기 때문일 수도 있다. (RP가 수신된 “age”와 “Nationality”를 가공하여 “CanDrink?”라는 클레임을 필요로 할 수도 있다.)

    위에서 언급한 것과 같은 새로운 제약 조건이 있을 경우, 이는 새로운 요소를 추가함으로써 쉽게 처리할 수 있다. 클레임 변환기 (claim transformer)로 불리게 될 이 요소는 리소스에 도달하기 전에 토큰을 처리할 수 있으며, RP가 신뢰를 중개하고 수신 클레임을 보다 적절한 형식으로 변환하는 데 활용할 수 있다. 주체와 RP 사이에는 임의의 긴 클레임 변환기 사슬이 존재할 수 있다. 따라서 상위 수준에서 계획하지 않고도, 동적인 정책 협상에서 경로(존재하는 경우)를 자동으로 “선택”할 수 있다.
    클레임 변환기를 구현하는 최상의 아티팩트는 다시 말하지만 STS이다. 클레임 변환기가 사용하는 STS는 자체 데이터 소스로부터 발급된 클레임을 채우는 것 대신, 주로 수신된 정보를 조작하게 된다. 전통적인 페더레이션 경우처럼, RP를 소유하고 있는 동일한 엔터티가 STS를 실행하는 경우가 많기 때문에, 이러한 종류의 STS는 일반적으로 Resource STS, R-STS 또는 RP-STS로 지칭된다. 보다 자세한 정보는 저자 블로그에서 확인하도록 한다(리소스 부분 참조).
    클레임 변환기를 적용하는 방식은 몇 가지 강력한 이점을 제공하며, 분산 시스템의 아이덴티티 관리를 위한 지배적인 패턴으로 부상할 것으로 생각된다(그림 3 참조).

    Cc836390_ClaimsAndIdentity03(en-us,MSDN_10)

    리소스 클러스터링
    클레임 변환기는 엔터프라이즈 수준에서 단일 리소스와 디렉터리 간에 지속적인 granularity를 제공할 수 있다. R-STS는 요구 사항이 비슷한 여러 리소스를 모으는 데 사용할 수 있다. 복잡한 신뢰 중개 나 원본 클레임 처리 작업을 엔터프라이즈 수준까지 요청할 필요도 없이 한 지점 내로 이동시킴으로써 정책 관리를 간소화한다. R-STS는 네트워크 상에서 제 역할을 제대로 하지 못할 수 있는 레거시 리소스를 보호하는 가상 경계도 될 수 있다. 이러한 것들은 클레임 변환기의 강력한 효과를 보여 주는 일부 사례에 지나지 않는다(그림 4 참조).

    Cc836390_ClaimsAndIdentity04(en-us,MSDN_10)

    권한 부여 결정 지점(Authorization Decision Point)
    IP는 일반적으로 독립적인 엔터티지만, R-STS는 협력하는 리소스의 일부 정보를 소유하는 경우가 많다. R-STS는 이러한 정보를 통해 권한 부여 결정을 내릴 수 있다. 수신 클레임은 주체가 접근을 시도하는 리소스의 요구 사항과 함께 처리될 수 있고, 그 결과는 곧 주체가 필요한 권한을 보유하고 있는지 여부에 관한 결정이 될 수 있다. 이러한 결정은 다양한 방식으로 표현될 수 있다.

    • 주체가 어떠한 권한도 가지고 있지 않은 경우, R-STS는 단순히 토큰 발급을 거부하고 호출을 차단할 수 있다. 이 경우 R-STS는 권한 부여를 강제하는 것이다.
    • 주체가 일정 권한을 가지고 있는 경우, R-STS는 이러한 권한 부여 결정을 클레임의 형태로 공식화할 수 있다. 따라서 RP는 권한 부여 로직을 실행해야 하는 부담에서 벗어나 R-STS에서 클레임의 형태로 받는 지시문을 적용하기만 하면 된다.

    토큰, 클레임 및 IP 사용은 인증 과정 외부화를 가능하게 하고, 어느 특정 상황에서 R-STS는 권한 부여 결정에도 동일한 작업을 수행할 수 있도록 도움을 줄 수 있다.

    위임
    레거시 시스템, 디렉터리 수준에서 직접 관리되는 리소스 등 클레임이 인식하지 않는 수많은 리소스가 존재한다. 때로는 이러한 리소스에 대한 접근을 관리하기 위해 ACL 할당 및 그룹 생성과 같이 몇 가지 투자가 이루어진 경우도 있다. 클레임 기반 보안을 통해 프런트 엔드 애플리케이션을 호출하는 주체의 아이덴티티는 이러한 투자를 활용하는 데 적합하지 않다. 단, 프런트 엔드 애플리케이션이 호출자를 대신하여 디렉터리 아이덴티티를 받을 수 있다면 문제가 해결된다. 사실 다른 누군가를 대신하여 토큰을 받는 것은 발급된 토큰이 클레임의 영역에 남아 있는 경우에도 분명히 가치가 있다.

    클레임과 클라우드
    지금까지 설명한 것의 장점은 느슨하게 연결된 모든 시스템에 적용될 수 있다는 것이다. 최고의 분산 시스템이라 할 수 있는 클라우드도 예외가 아니다. 클라우드 차원에서 생각한다는 것은 모든 엔터티가 독립적으로 관리되는 환경을 다루는 것이다. 즉, 클레임, 토큰, 신뢰 및 아이덴티티 메타 시스템 기능은 다루고 있는 파티들 사이의 관계에 대해 알고 있는 정보의 크기가 얼마가 됐든 이를 최대한 활용할 수 있도록 지원한다. 클레임 기반 솔루션을 설명하면서 우리는 사내 및 클라우드에 모두 비슷하게 적용될 수 있는 도구를 제공하는 일석이조의 효과를 거두었다.
    우리가 클라우드 시나리오에 대한 자세한 지침을 제공하기에는 앞으로 어떤 식으로 변하게 될지 너무 적게 알고 있는 실정이다. 하지만 몇 가지 기본적인 가설을 통해 클라우드에 특히 잘 맞는 클레임 인식 아이덴티티 관리의 여러 가지 측면은 조명해 볼 수 있다.

    클레임 변환을 통한 접근 제어
    클라우드 공급자가 저장 및 계산, 메시징, 통합 등과 같은 서비스를 제공할 수 있다는 것은 잘 알려진 사실이다. 클레임 변환기 섹션에서 다뤘던 내용을 상기해보면, 클라우드 공급자의 분명한 접근 제어 전략은 R-STS를 제공하고 리소스가 이를 신뢰하게 만드는 것임을 알 수 있다. 그러면 이 R-STS를 사용하는 모든 리소스들은 R-STS의 클레임 변환 규칙을 조작함으로써 간단하게 접근 제어를 관리할 수 있게 된다.
    ISV로서 어떤 클라우드 공급자에 서비스를 구축하기를 원한다고 가정해 보자. 먼저 서비스가 받아들일 클레임 집합을 결정하고, 이 서비스가 클라우드 공급자의 R-STS를 신뢰하도록 설정한다. 이로써, 누가 서비스를 호출하더라도 접근 제어 전략은 이미 마련되어 있다! 새로운 고객을 참여시킬 때에는 R-STS 수준에서 몇 가지 규칙을 설정하여 고객의 클레임을 자신의 클레임으로 매핑하는 방법을 정의하기만 하면 된다. 이는 놀라울 정도로 민첩한 방법으로 유지 관리하기도 매우 쉽다(그림 5 참조).

    Cc836390_ClaimsAndIdentity05(en-us,MSDN_10)

    권한 부여 외부화 (Externalizing Authorization)
    지금까지 R-STS가 권한 부여 결정을 편리하게 외부화하고 집계하는 방법에 대해 살펴보았다. 물론 이 방법은 클라우드 시나리오에서도 유효하다. 실제로는 권한 부여 적용까지 포함하도록 R-STS의 적용 범위가 확대된 사례가 많다. ISV 사례로 돌아가자.
    서비스가 메시징 방식을 통해 제공되는 경우, 메시지가 타겟에 도달하기 전에 권한 부여에 관련된 클레임을 검사함으로써, 서비스 전송 인프라 자체에서 권한 부여 결정 사항을 강제할 수 있다. 이는 ISV의 부담을 줄여준다. 즉, 서비스가 해당 공급자의 메시징 인프라를 사용하지 않는 경우, 권한 부여 관련 결정 사항을 강제하기 위해서는 리소스 앞쪽에 일부 처리 파이프라인을 추가해야 하는 부담이 발생하게 된다. (보다 자세한 내용은 리소스 부분 참조: Vittorio Bertocci의 블로그, 클레임 유형).

    관계 관리하기
    설명한 모델을 통해 ISV는 고객 관계를 일련의 규칙으로 나타낼 수 있다. 이는 전통적인 방법을 통해 디렉터리 간에 페더레이션 관계를 생성하는 것보다 훨씬 더 민첩한 방식이다. 이 방식은 관리의 세분성은 떨어지지만, 피어 파트너 관계에는 필요하나 공급자-고객 관계에는 과도한 경우가 많은 추가 관리 부담을 해소시켜 준다.
    또한, 이 모델은 고급 아이덴티티 기능 없이도 개인 및 고객을 수용할 수 있게 해 준다. ISV 서비스는 고객이 자체 IP에서 발급된 토큰을 통해 인증을 받았든, 단순한 일회용 사용자 이름 및 암호를 통해 인증을 받았든, 언제나 R-STS가 발급한 토큰을 확인한다.

    미래
    클라우드로의 전환은 확실히 이루어질 것이다. 업계에서는 중요한 것은 클라우드 환경으로 전환할지 여부가 아니라 전환 시점이라는 것을 매우 빠르게 인식하고 있다. 미래를 예측하는 것은 언제나 위험한 일이다. 하지만 클라우드는 오늘날 아이덴티티 유토피아처럼 보임에도 불구하고 지금까지 설명한 원리 덕분에 지극히 타당해 보이는 개발에 뛰어들지 않고 그냥 넘기기에는 너무 들떠 있는 상황이다.
    오늘날 접근 제어는 기능보다는 순위를 반영하는 권한으로 인해 조직 구조의 철로에서 제약을 받는 경우가 많다. 상호 운용성 이벤트에 참여하는 기업 및 오픈 소스 이니셔티브의 수와 수준(리소스 부분 참조: RSA 2008 OSIS 상호 운용성 이벤트), 그리고 주요 제품에서의 클레임 지원 통합은 클레임 기반 프로그래밍이 주류가 되고 있음을 보여준다. 그렇게 된다면 아이덴티티 및 접근 제어 구조가 어떻게 조직이 아닌 작업을 중심으로 수렴될 수 있을지를 쉽게 상상할 수 있다. 수많은 기업의 주체, 리소스, 역할 및 인증 기관은 모두 특정 프로젝트의 측면에서 설명될 수 있고, 조직 순위가 아닌 프로젝트 자체의 측면에서 수행되는 기능에 따라 권한이 할당될 것이다. 작업이 이루어지는 동안에는 가상 조직이 생성되었다가 임무가 완료되면 사라질 수 있다. 또한, 기업 전체에서 이루어지는 작업 템플릿을 지원하여, 모범 사례를 적용하고, 예측 가능성을 향상시킬 수 있다(그림 6 참조).

    Cc836390_ClaimsAndIdentity06(en-us,MSDN_10)

    이를 실현하려면 클레임은 충분조건이 아닌 필요조건이다. 여기에 가상 디렉터리와 같은 새로운 기술이 또한 핵심 역할을 할 것이다. (보다 자세한 내용은 Kim Cameron의 블로그 www.identityblog.com을 참조할 것).

    Call to Action
    클레임 기반 방식은 전통적인 시나리오와 클라우드 시나리오 모두를 위한 훌륭한 방식이다. 차이가 있다면 전통적인 시나리오에서는 경우에 따라 다량의 추가 리소스를 사용하여 나쁜 전략을 피할 수 있는 반면, 일단 클라우드를 사용하는 경우에는 이것이 쉽지 않다는 것이다. 자신과 조직이 미래의 물결에 대비하길 원한다면 다음과 같은 몇 가지 작업을 수행할 수 있다.

    여기서 ‘수박 겉핥기 식’이라는 속담을 언급할 수 있을 듯하다. 그리고 아마 그 말이 맞을지도 모른다. 하지만 그 대신 클레임은 전통적인 시나리오와 클라우드 시나리오 모두에 있어 흥미로운 아이덴티티 관리 전략 개발의 토대가 된다는 말로 이 글을 정리하고 싶다. 자신이 괴짜라고 생각한다면 이러한 상호 작용의 대부분이 아주 명백히 드러나는 특별한 전환의 순간을 즐기라고 권하고 싶다. 그리고 아울러 그 외 사람들에게는 세부 정보의 대부분은 인프라에 통합되고 새로운 차원의 도구를 통해 겉으로 드러나지 않을 것으로 예상되기 때문에 안심해도 된다고 말하고 싶다.

    리소스
    Vittorio Bertocci의 블로그:

    Kim Cameron의 블로그:

    “Understanding Windows Cardspace”, Chapter II (Addison Wesley 2008)(MSDN에 게시)

    RSA2008 OSIS 상호 운용성 이벤트:

    WS-Security

    WS-Trust:

    저자 소개
    Vittorio Bertocci는 Microsoft사 Cloud Services Evangelism의 수석 아키텍트 전도사로 대기업이 신기술을 활용할 수 있도록 도움을 주고 있다. 그는 Italian Microsoft Services에서 몇 년간 근무한 후, 미국 본사로 전근하여 지난 3년간 고객이 아이덴티티 및 접근 관리, SOA 및 서비스를 토대로 솔루션을 구축할 수 있도록 지원해 왔다. 현재 클라우드 컴퓨팅의 아이덴티티 및 접근 측면에 전념하고 있으며, 사용자 중심의 ID를 주제로 공동 집필한 저서 Understanding Windows Cardspace가 지난 1월에 출간된 바 있다. Vittorio는 유명한 블로그(http://blogs.msdn.com/vbertocci)를 운영하고 있다.
    이 글은 Microsoft가 출판하고 온라인으로 게시하는 Architecture Journal에 실려 있다. Architecture Journal에서 더 많은 글을 읽고 싶다면 Architecture Journal 웹 사이트를 참조한다.

  • Korea Evangelist

    8월 개발자 세미나 소셜웹 개발 플랫폼 18일 시작됩니다.

    • 0 Comments

    개발자들을 위해서 한 달에 두 번씩 세미나를 진행하겠다고 앞서서 이야기 한 적이 있었습니다. ^^
    http://www.youngwook.com/398
    이제 실제로 '코드 파티'라는 이름으로 본 세미나를 진행하게 되었습니다. 이번달은 18일과 25일 양일에 걸쳐서 '소셜 웹 플랫폼'이라는 주제로 지난 달에 발표된 ASP.NET Razor와 엔터프라이즈 소셜 웹 플랫폼인 SharePoint Server를 주제로 진행하게 되었습니다. 멋진 강사들과 새로운 방식으로 시작하는 코드 파티에 지금 등록하세요~!!

    등록
    은 아래 링크에서 가능합니다.
    http://new.imaso.co.kr/seminar_inquiries/add/codeparty1   <----- 등록

  • Korea Evangelist

    윈도우 애저 트레이닝 킷 한국어 번역 자료 #1

    • 0 Comments

    윈도우 애저 트레이닝 킷 에 있는 따라하기(Demo)와 핸즈온랩(HOL) 한국어 번역 자료를 제 블로그 를 통해서 공개하고 있습니다. 처음 접하시는 분들도 매우 쉽게 따라해 보실 수 있는 형태로 되어 있으므로 클라우드 개발에 관심이 있는 분들께 도움이 되길 바랍니다.

    간단한 따라하기와는 다르게 핸즈온랩은 실제 개발을 진행해 볼 수 있으며, 여러가지 개발과 관련한 설명들이 포함이 되어져 있습니다. 한 주 동안 추가된 한국어 번역 자료를 이곳을 통해서도 공유 하도록 하려고 합니다. 각각은 워드 파일과 파워포인트 파일로 되어 있으며 스카이 드라이브에 올려져서 오피스 웹 앱 형태로 실행되도록 링크되어 있습니다.

    <윈도우 애저 – 따라하기(Demo) 강좌>
    [한국어 애저 자료] 따라하기 01 윈도우 애저 서비스 배포하기
    [한국어 애저 자료] 따라하기 02 Hello 윈도우 애저
    [한국어 애저 자료] 따라하기 03 방명록 데모
    [한국어 애저 자료] 따라하기 04 로깅과 설정
    [한국어 애저 자료] 따라하기 05 Blob 저장소 사용하기

    <윈도우 애저 – 핸즈온랩(HOL) 강좌>
    [한국어 애저 자료] 핸즈온랩 01 개발자를 위한 윈도우애저 소개

    <윈도우 애저 – 발표자료(PPT) 강좌>
    [한국어 애저 자료] 발표자료 01 윈도우 애저 플랫폼 소개 & 02 윈도우 애저 소개

Page 4 of 4 (20 items) 1234