내보내기(0) 인쇄
모두 확장

Azure AD를 사용하여 웹 응용 프로그램에 로그온 기능 추가

업데이트 날짜: 2014년 5월

note참고
이 예제는 오래된 버전입니다. 기술, 방법 및/또는 사용자 인터페이스가 새로운 기능으로 대체되었습니다. 유사한 응용 프로그램을 빌드하는 업데이트된 예제를 보려면 WebApp-OpenIDConnect-DotNet을 참조하십시오.

.

이 연습에서는 Azure AD를 사용하여 ASP.NET 응용 프로그램에서 웹 Single Sign-On을 구현하는 방법을 보여 줍니다. 이 과정에서 조직의 LOB(기간 업무) 응용 프로그램용 ID 공급자로 널리 사용되는 Azure 구독과 연결된 디렉터리 테넌트를 활용하는 방법을 중점적으로 설명합니다.

웹 Single Sign-On 솔루션에서는 일반적으로 인증 기능을 단일 외부 엔터티로 아웃소싱하도록 웹 응용 프로그램을 구성합니다. 이러한 외부 엔터티를 보통 IDP(ID 공급자)라고 합니다. 구체적으로 설명하자면 이 방식은 SAML-P, WS-Federation, OpenID Connect 등의 일부 로그온 프로토콜에 따라 인증되지 않은 요청을 IDP로 리디렉션하도록 응용 프로그램을 구성한다는 의미입니다.

해당 기관, 즉 IDP가 인증 환경의 작업을 처리하며 일반적으로는 특정 프로비저닝 프로세스를 통해 웹 응용 프로그램이 이미 확인된 상태여야 합니다. 인증이 정상적으로 완료되면 브라우저는 들어오는 사용자에 대한 정보를 포함하는 보안 토큰과 함께 웹 응용 프로그램으로 리디렉션됩니다. 응용 프로그램은 보통 ID 인식 미들웨어를 통해 토큰의 유효성을 검사하며 확인이 성공하면 사용자는 인증된 것으로 간주되어 로그인됩니다.

위의 대략적인 설명이 Azure AD에도 적용됩니다. 이 문서에서는 .NET Framework 4.5의 WIF(Windows Identity Foundation) 클래스 및 Visual Studio 2012를 사용하여 웹 로그온 프로토콜을 사용하도록 MVC 4 응용 프로그램을 구성하는 방법에 대해 설명합니다. 또한 동일한 응용 프로그램을 Azure AD 테넌트에서 프로비저닝하는 방법과 해당 테넌트에 연결하도록 응용 프로그램 로그온 설정을 구성하는 방법도 설명합니다. 연습을 완료하면 정상적으로 작동하며 조직의 Single Sign-On용으로 완전하게 구성된 웹 응용 프로그램이 완성됩니다.

이 연습의 목표는 Azure AD의 작동 방식을 이해하는 것입니다. 해당 방식을 완전하게 이해하려면 여기서 설명하는 단순한 솔루션을 작성하기 위한 지침보다 자세한 설명을 확인해야 합니다. 따라서 이 문서에서는 작동하는 샘플을 작성하기 위한 구체적인 지침을 제공하는 동시에, Azure AD에 대해 파악하고 여기서 설명하는 구체적인 시나리오 이외의 경우에도 해당 기능을 활용하는 방법을 이해하는 데 유용한 여러 가지 개념과 요소에 대해서도 소개합니다. 참고 사항 형식으로 제공되는 이러한 추가 섹션은 연습을 진행하는 과정에서 반드시 필요한 것은 아니지만 자신의 솔루션에서 Azure AD를 사용하려는 경우에는 해당 부분도 파악하는 것이 좋습니다.

이 문서의 자습서 부분은 다음 섹션으로 구성되어 있습니다.

  • 필수 구성 요소: 이 섹션에는 연습을 완료하려면 충족해야 하는 모든 요구 사항이 나와 있습니다.

  • 솔루션 아키텍처: 이 섹션에서는 LOB(기간 업무) 응용 프로그램용 웹 SSO 솔루션의 표시 방식에 대해 간략하게 소개합니다. 이 과정에서 SSO를 작동하도록 하는 기능적 구성 요소를 살펴보고 문서 뒷부분의 지침에 따라 작성할 솔루션의 토대를 설정합니다.

  • Azure AD 디렉터리 테넌트 사용:이 섹션에서는 이 문서의 시나리오에서 사용할 Azure AD 테넌트 및 기능에 대해 소개합니다. 또한 Azure 관리 포털의 Active Directory 섹션에 포함된 주요 요소에 대해서도 간략하게 설명합니다.

  • Azure AD에 응용 프로그램 연결: 이 섹션에서는 Visual Studio 2012용 ID 및 액세스 도구를 사용하여 MVC 응용 프로그램에서 웹 Single Sign-On을 사용하도록 설정하고, 선택한 특정 Azure AD 테넌트에 인증 설정을 연결하는 방법을 설명합니다.

  • 고급 항목: 이 섹션에서는 일부 주요 항목에 대해 기본적인 사항보다 좀 더 자세한 설명을 제공하고, 응용 프로그램을 보다 높은 수준으로 활용하기 위해 수행해야 할 수 있는 몇 가지 기타 작업에 대해 다룹니다.

이 자습서의 작업을 완료하려면 다음 필수 구성 요소가 필요합니다.

의문 사항이 있거나 도움이 필요하면 Preparing for Azure AD Solutions and Scenarios를 참조하십시오.

단일 테넌트 응용 프로그램 아키텍처

이 연습에서 중점적으로 살펴볼 시나리오에서는 개발자가 웹 응용 프로그램을 클라우드에 배포하려 한다고 가정합니다. 이 개발자는 Azure Active Directory 테넌트의 사용자에게만 액세스를 허용하려고 합니다. 이렇게 하려면 개발자는 다음을 수행해야 합니다.

  1. Azure AD 테넌트에 웹 응용 프로그램을 등록해야 합니다. 응용 프로그램이 확인되면 Azure AD는 해당 응용 프로그램에 대한 사용자의 인증 요청을 수락합니다.

  2. 다음 작업이 가능하도록 응용 프로그램에 특정 항목을 추가합니다.

    1. 인증되지 않은 요청을 차단하고 사용자 인증을 위해 올바른 Azure AD 테넌트로 리디렉션

    2. Azure AD에 인증된 사용자를 인식하여 액세스 권한 부여

첫 번째 단계는 Azure 관리 포털을 사용하여 구현합니다. 이를 위해 Azure 구독 내에서 새 Azure AD 테넌트를 프로비저닝하는 방법과, Azure AD 관리 포털 기능을 사용하여 응용 프로그램을 등록하는 방법을 살펴봅니다.

2단계는 조직 경계 간이나 인터넷을 통한 인증 작업을 허용하는 다양한 고급 프로토콜을 사용하여 구현할 수 있습니다.

.NET 플랫폼에서 2단계를 수행하는 경우에는 클레임 기반 ID 및 페더레이션 인증용으로 사용할 수 있도록 .NET에서 기본 제공되는 클래스를 구성하게 됩니다. WIF(Windows Identity Foundation)로 총칭하는 이러한 클래스는 2단계에서 소개하는 리디렉션 및 인증 작업을 수행하기 위한 가로채기 계층을 추가하는 데 사용할 수 있는 HTTP 모듈 및 구성 설정을 포함합니다. Visual Studio 2012에서는 웹 응용 프로그램이 WIF를 사용하여 WS-Federation 등의 특정 웹 SSO 프로토콜을 지원하는 외부 기관으로 인증을 아웃소싱하도록 자동 구성할 수 있는 도구를 제공합니다. 이 연습에서는 Azure AD에서 그러한 도구를 사용하는 방법을 설명합니다.

Azure Active Directory는 Office 365 및 Windows Intune과 같은 Microsoft 제품의 ID 백본을 제공하는 서비스입니다. 이러한 서비스를 구독하는 경우 해당 서비스에 연결된 디렉터리 테넌트를 다시 사용하려면 새 Azure 구독을 만든 다음 사용자 추가 기능을 사용하여 해당 테넌트에서 관리자를 추가합니다. 이 연습에서는 해당 프로세스에 대한 자세한 지침을 제공하지는 않습니다.

모든 구독에는 Azure AD 테넌트 및 연결된 디렉터리가 있습니다. 테넌트가 자동으로 생성된 경우 디렉터리 이름은 기본 디렉터리로 지정되지만 변경할 수 있습니다. 이 연습 부분에서는 디렉터리에 사용자를 추가한 다음 응용 프로그램을 추가합니다.

디렉터리 테넌트를 만들면 클라우드에 사용자와 자격 증명을 저장하도록 구성됩니다. 디렉터리 테넌트를 온-프레미스에 배포된 Windows Server Active Directory와 통합하는 방법에 대한 자세한 지침은 디렉터리 통합을 참조하십시오.

의문 사항이 있거나 도움이 필요하면 Preparing for Azure AD Solutions and Scenarios를 참조하십시오.

Azure AD 시나리오 및 솔루션과 이 문서에서 제공하는 코드 샘플 및 샘플 응용 프로그램을 사용하려면 Azure Active Directory의 도메인에 사용자 계정이 필요합니다. Hotmail.com, Live.com, Outlook.com 계정과 같은 Microsoft 계정을 사용하여 응용 프로그램에 로그인하려고 하면 로그인이 실패합니다. 사용자에게 Active Directory 도메인의 계정(예: User@Contoso.onmicrosoft.com 계정)이 이미 있는 경우에는 해당 계정을 사용하여 이 시나리오에서 사용하는 응용 프로그램에 로그인할 수 있습니다. 그렇지 않으면 사용자를 새로 만들어야 합니다.

  1. Microsoft Azure 관리 포털(https://manage.WindowsAzure.com)로 이동하여 로그인한 다음 Active Directory를 클릭합니다. (문제 해결 팁: "Active Directory" 항목이 없거나 사용할 수 없음)

  2. 디렉터리의 이름이 "기본 디렉터리"이면 "ContosoEngineering"과 같은 디렉터리를 추가합니다. 디렉터리를 추가하려면 Active Directory 페이지 아래쪽에서 추가를 클릭하고 지침에 따라 새 디렉터리를 추가합니다.

  3. 디렉터리를 두 번 클릭하고 도메인을 클릭합니다. 사용자 계정을 만들 때는 페이지에 표시되는 도메인 이름을 사용합니다. 예를 들어 도메인이 ContosoEngineering@onmicrosoft.com이면 Test@ContosoEngineering@onmicrosoft.com과 같이 해당 도메인의 사용자 이름을 만듭니다.

  4. 도메인에서 사용자 계정을 만들려면 사용자를 클릭합니다. 사용자 탭이 표시되지 않으면 디렉터리 이름을 두 번 클릭합니다. 그러면 각 디렉터리 관련 페이지에 사용자 탭이 표시됩니다. 페이지 아래쪽에서 사용자 추가를 클릭합니다.

  5. 조직의 새 사용자를 선택합니다. Test@ContosoEngineering.onmicrosoft.com과 같은 새 도메인의 사용자를 추가하고 페이지 아래쪽의 확인 표시를 클릭합니다.

    사용자 이름 및 도메인 입력
  6. 사용자 프로필 페이지에서 조직 역할을 사용자에게 할당합니다. 테스트용으로는 전역 관리자 역할의 사용자와 사용자 역할의 사용자를 각각 한 명 이상 지정하는 것이 가장 좋습니다.

    사용자 역할 입력

마지막 단계에서는 Azure 관리 포털에서 사용자가 최초 로그인 시 사용하는 임시 암호를 생성합니다. 최초 로그인이 완료되면 사용자는 임시 암호를 변경해야 합니다. 임시 암호는 시나리오를 테스트하는 데 사용해야 하므로 저장해 두십시오.

이제 웹 Single Sign-On 시나리오에서 인증 기관을 제공하기 위한 올바른 사용자가 포함된 디렉터리 테넌트가 생성되었습니다.

임시 암호

  1. 먼저 응용 프로그램을 만드는 작업부터 시작하겠습니다. Visual Studio를 열고 새 프로젝트를 클릭한 다음 ASP.NET MVC 4 웹 응용 프로그램을 선택합니다. 새 ASP.NET MVC 4 프로젝트 창에서 인트라넷 응용 프로그램을 선택하고 뷰 엔진이 Razor로 설정되어 있는지 확인한 후에 확인을 클릭합니다. 이 연습에서는 프로젝트 이름으로 ExpenseReport를 사용합니다.

    note참고
    이 연습에서는 설치된 Visual Studio가 기본 설정으로 구성되어 있다고 가정합니다. 개발 시 웹 응용 프로그램이 호스팅되는 위치 등의 일부 기본 구성을 변경한 경우에는 그에 따라 지침을 적절하게 조정해야 합니다.



    Visual Studio의 새 프로젝트

    ASP.NET 요청 처리 파이프라인을 크게 변경하는 논리가 없다면 이 연습의 지침은 모든 기존 VS 2012 웹 응용 프로그램, MVC 또는 Web Forms에 적용할 수 있습니다. 그러나 이 문서에서는 간편한 설명을 위해 새 프로젝트를 처음부터 작성합니다.

    note참고
    이 연습에서는 .NET 솔루션을 설정하는 방법에 대한 자세한 지침을 제공합니다. 그러나 다른 플랫폼 및 프로그래밍 스택을 대상으로 지정해도 같은 결과를 얻을 수 있습니다. Azure AD는 웹 로그온 기능에서 개방형 프로토콜을 사용하며 그러한 프로토콜을 지원하는 모든 주요 플랫폼 기능, 라이브러리 및 도구를 사용합니다. 이 문서에서 설명하는 세부 단계는 모든 스택의 구문과 방식에 맞게 조정해야 하지만, 대략적인 작업 구분은 전반적인 스택에 적용됩니다.

    Visual Studio에서는 IIS Express에서 실행되도록 이미 구성된 새 MVC 프로젝트가 자동으로 작성됩니다. 웹 로그온을 추가하는 방법을 설명하는 데는 이 프로젝트의 기본 기능만으로도 충분하므로 여기서는 해당 프로젝트에 기능을 더 추가하지는 않습니다. 단, 응용 프로그램에서 사용하는 끝점은 예외입니다. Visual Studio는 기본적으로 HTTP를 통해 콘텐츠를 제공하도록 응용 프로그램을 구성합니다. 그러나 보안 시나리오를 설정하려는 경우 이러한 구성은 적합하지 않습니다. 이처럼 구성하는 경우 통신이 보호되지 않으며 잠재적 공격자들이 쿠키와 토큰을 도용할 수 있기 때문입니다. Azure에서는 반드시 HTTPS를 사용해야 하는 것은 아니므로 개발 단계에서 HTTPS를 구성할 필요는 없습니다. 그러나 가능하면 항상 HTTPS를 사용하는 것이 좋습니다.

  2. IIS Express를 사용하면 Visual Studio에서 직접 HTTPS를 사용하도록 설정할 수 있습니다. 이렇게 하려면 솔루션 탐색기에서 프로젝트를 선택하고 속성 창에서 SSL 사용True로 전환합니다.

    이전에 비어 있던 SSL URL에 새 주소가 채워집니다. 해당 주소를 선택하고 클립보드에 복사합니다.



    SSL URL 복사

  3. 이제 디버그 중에 항상 HTTPS 끝점을 사용할 것임을 Visual Studio에서 지정해야 합니다. 솔루션 탐색기로 돌아가서 프로젝트를 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다. 왼쪽의 탭을 선택하고 아래쪽의 로컬 IIS 웹 서버 사용 옵션으로 스크롤한 다음 프로젝트 URL 필드에 HTTPS URL을 붙여 넣습니다. Ctrl+S를 눌러 설정을 저장하고 속성 탭을 닫습니다.



    프로젝트 URL 변경

    이제 응용 프로그램이 로그온 시 Azure AD를 활용하도록 구성할 수 있는 상태가 되었습니다. 다음 단계에서는 Azure AD 테넌트가 이 특정 응용 프로그램을 인식하도록 구성합니다.

  1. Visual Studio를 최소화하고 Azure 관리 포털의 Active Directory 탭으로 돌아갑니다. 연습 앞부분에서는 사용자 영역을 사용했습니다. 이번에는 응용 프로그램 영역을 사용합니다. 페이지 위쪽에서 응용 프로그램을 클릭합니다.



    통합된 앱

    이 영역에는 디렉터리 테넌트에 등록된 응용 프로그램이 표시됩니다. 다음과 같은 경우 응용 프로그램은 테넌트에 등록되어 있는 것입니다.

    • 응용 프로그램 이름, 연결된 끝점 등의 기본 정보를 설명하는 항목이 디렉터리에 있는 경우. 자세한 내용은 뒷부분에서 설명합니다.

    • 응용 프로그램 자체에 현재 디렉터리 테넌트에서 일부 작업을 수행하기 위한 사용 권한이 부여된 경우. 이러한 작업으로는 로그온 토큰 요청, 디렉터리 쿼리 등이 있습니다. 역시 자세한 내용은 뒷부분에서 설명합니다.

    Important중요
    등록되지 않은 응용 프로그램은 Azure AD를 사용할 수 없습니다. 이는 보안상의 이유(관리자가 승인하는 응용 프로그램만 허용해야 함)와 실제적인 고려 사항(Azure AD와 상호 작용할 때는 특정 개방형 프로토콜을 사용하므로 응용 프로그램에 대해 설명하는 주요 매개 변수를 파악해야 함)으로 인한 것입니다.

  2. 방금 이 디렉터리 테넌트를 새로 만들었으므로 등록된 응용 프로그램 목록은 아직 비어 있습니다. 실제로 방금 Visual Studio에서 만든 응용 프로그램이 첫 번째 항목이 됩니다. 이 섹션 전체에서는 해당 응용 프로그램을 등록하는 방법에 대해 중점적으로 설명합니다.

    이 응용 프로그램이 첫 번째 응용 프로그램이라는 가정 하에 화면 아래쪽의 Azure 관리 포털 명령 모음에서 추가 단추를 클릭하여 프로세스를 시작합니다. 그러면 아래와 같은 화면이 표시됩니다.



    앱에 대한 정보 입력

    Azure 관리 포털을 통해 응용 프로그램 하나를 등록하는 프로세스는 클래식 마법사 구조로 진행됩니다. 따라서 여러 후속 화면이 순서대로 표시되면서 사용자가 선택하는 항목에 따라 필요한 정보를 수집합니다.

    위 그림에는 이러한 화면 중 첫 번째 화면이 표시되어 있습니다. 이러한 화면을 통해 제공되는 옵션은 단순합니다.

    • 표시 이름: 여기에 입력하는 텍스트는 사용자가 읽을 수 있는 모니커로 사용됩니다. 사용자(등록된 응용 프로그램 목록을 관리하는 관리자 또는 응용 프로그램에 디렉터리 액세스 권한을 부여하려는 고객)는 응용 프로그램에 대한 작업을 수행해야 할 때마다 해당 모니커를 통해 응용 프로그램을 참조합니다. 여기에 대한 자세한 정보는 Azure AD를 사용하여 다중 테넌트 웹 응용 프로그램 개발 백서에 나와 있습니다.

    • 액세스 유형: 이 라디오 단추 집합을 사용하면 디렉터리 테넌트에 대해 응용 프로그램이 수행하도록 허용할 작업을 지정할 수 있습니다. 이 자습서에서는 응용 프로그램을 사용한 웹 로그온만 구성하면 되므로 Single Sign-On을 선택하면 됩니다.

      note참고
      응용 프로그램 사용 권한 항목에 대해 자세히 설명하는 백서도 있지만, 여기서는 백그라운드에서 수행되는 작업을 파악할 수 있도록 원칙적인 내용만 간략하게 언급하고 넘어가겠습니다.

      Azure AD는 ServicePrincipal이라는 엔터티를 사용하여 응용 프로그램을 표시합니다. 이름에서 알 수 있듯이 이러한 엔터티는 널리 사용되는 사용자 계정과 동일하지만 응용 프로그램을 설명하는 데 사용됩니다.

      응용 프로그램을 등록하는 작업은 실제로는 해당 응용 프로그램에 액세스 권한을 제공할 디렉터리 인스턴스의 테넌트에서 응용 프로그램에 대해 ServicePrincipal을 만드는 것입니다.

      지정된 응용 프로그램에 대해 부여해야 하는 액세스 수준은 해당하는 ServicePrincipal이 속하는 역할에 따라 결정됩니다. 이 연습에서는 읽기 및 쓰기 액세스 수준을 선택할 필요가 없지만 해당 수준을 선택해야 하는 경우에는 등록 흐름에서 보다 자세한 정보 수집을 위한 몇 가지 단계가 더 추가됩니다. 이러한 정보에는 쿼리 수행 시 인증에 사용할 키 등이 있습니다. 이 경우에는 해당 키도 응용 프로그램을 설명하는 ServicePrincipal에 저장됩니다. 여기에 대한 자세한 내용은 Graph API를 사용하여 Azure AD 쿼리 항목에 나와 있습니다.

      응용 프로그램 등록 프로세스를 통해 부여되는 사용 권한은 디렉터리 자체에 액세스할 때만 적용되며 SQL Azure 데이터베이스, 관리 포털 섹션 및 유사한 항목과 같은 기타 Azure 리소스에 대한 액세스 정책을 결정하지는 않습니다.

  3. 응용 프로그램 이름을 입력하고 Single Sign-On 액세스 유형을 선택한 후 오른쪽 아래의 화살표를 클릭하여 다음 화면으로 이동합니다.

    앱 속성 이 화면에서 Azure 관리 포털은 서비스가 로그인 프로토콜 흐름을 진행하는 데 필요한 중요 정보를 수집합니다. 입력해야 하는 정보는 다음과 같습니다.

    • 응용 프로그램 URL: 이 매개 변수는 웹 응용 프로그램의 address를 나타냅니다. 이 예에서 해당 URL은 https://localhost:44341/(IIS Express에서 응용 프로그램에 할당한 주소)에 해당합니다. 지금까지의 지침을 정확히 따른 경우에는 해당 주소가 아직 클립보드에 저장되어 있으므로 붙여 넣을 수 있는 상태입니다. 입력하는 값은 개발 단계를 진행하는 동안 계속 사용됩니다. 응용 프로그램을 대상 스테이징 환경 또는 프로덕션 환경에 배포한 후에는 관리 포털로 돌아와서 새 응용 프로그램 위치와 일치하도록 주소를 수정해야 합니다. 해당 작업을 수행하는 방법은 연습 뒷부분에서 설명합니다.

      Warning경고
      Azure AD가 응용 프로그램의 주소를 확인할 수 있어야 사용자가 Azure AD 페이지에서 정상적으로 인증된 후 인증 흐름을 응용 프로그램으로 다시 리디렉션할 수 있습니다.

      따라서 이 주소를 미리 입력해야 합니다. Azure AD에서 인증 흐름을 특정 주소로 리디렉션하는 경우 공격자가 인증 흐름을 하이재킹하고 토큰을 도용하기가 더 쉬워집니다. 응용 프로그램 URL을 미리 등록해 두면 응용 프로그램용 인증 토큰이 응용 프로그램으로만 전송됩니다.

    • 앱 ID URI: 이 매개 변수는 웹 응용 프로그램의 identifier를 나타냅니다. Azure AD는 로그온 시에 이 값을 사용하여 인증 요청을 통해 사용자가 등록된 모든 응용 프로그램 중에서 지정된 특정 응용 프로그램에 액세스할 수 있는지를 확인함으로써 올바른 설정을 적용할 수 있도록 합니다.

    note참고
    앱 ID URI는 디렉터리 테넌트 내에서 고유해야 합니다. 이 URI의 적절한 기본값은 응용 프로그램 URL 값 자체이지만 해당 전략을 사용하는 경우 고유성 제약 조건을 항상 쉽게 준수할 수 있는 것은 아닙니다. IIS Express, Azure Fabric Emulator 등의 로컬 호스팅 환경에서 응용 프로그램을 개발하면 여러 개발자 또는 동일 개발자의 여러 프로젝트에서 다시 사용되는 제한적인 주소 범위가 생성될 가능성이 높습니다. 이러한 경우 사용할 수 있는 전략 중 하나는 응용 프로그램 URI 값에 구별자를 추가하는 것입니다.

    또한 앱 ID URI는 URI이므로 네트워크 주소 지정 가능 끝점에 해당하지 않습니다. 그러므로 응용 프로그램 URL과는 관계가 없는 항목을 선택할 수도 있습니다. 이 자습서에서는 새 응용 프로그램을 만들지만 실제로는 자체 앱 ID URI가 이미 있는 기존 응용 프로그램을 등록하는 경우도 있습니다. 여기서 사용하는 로그온 프로토콜인 WS-Federation에서는 앱 ID URIrealm이라고 합니다. 이러한 경우에는 해당 URI를 여기서 사용해도 됩니다. 다중 테넌트 지원 시 추가로 발생하는 몇 가지 제약 조건에 대해서는 Azure AD를 사용하여 다중 테넌트 웹 응용 프로그램 개발 항목에서 자세히 설명합니다.

  4. 응용 프로그램 URL 및 앱 ID URI를 입력한 다음 오른쪽 아래의 확인란 단추를 클릭하면 됩니다.

    빠른 시작 이제 등록 프로세스가 완료되었으며 응용 프로그램의 항목이 디렉터리 테넌트에 포함되었습니다. 그리고 Azure AD에서 응용 프로그램 대신 웹 인증을 처리할 준비가 되었습니다.

    등록 성공을 알리는 화면에는 로그온에 Azure AD를 사용하도록 웹 응용 프로그램을 구성하는 데 필요한 정보가 표시됩니다. 예를 들어 Azure AD에서 Single Sign-On 사용 섹션에는 Visual Studio에 다시 붙여 넣어야 하는 두 가지 설정이 있습니다.

    브라우저에서 이 페이지를 열어 두고 Visual Studio로 다시 전환해 연습의 다음 작업을 진행합니다.

Azure AD가 응용 프로그램용 인증 토큰을 발급할 준비가 되었으므로 웹 로그온을 사용하도록 설정하기 위한 마지막 단계에서는 올바른 인증 프로토콜을 사용하여 요청을 처리하도록 응용 프로그램 자체를 구성합니다. 프로토콜을 적용하면 사용자가 응용 프로그램을 사용하여 작업 세션을 시작할 때 응용 프로그램이 Azure AD(구체적으로는 디렉터리 테넌트)를 호출하여 사용자 인증을 처리할 수 있습니다.

웹 로그온 프로토콜을 사용할 때는 인증 역학의 몇 가지 배경 정보를 이해해야 합니다. 이와 관련한 자세한 내용은 고급 섹션에 나와 있습니다.

여기서 선택한 프로젝트 템플릿은 MVC 4 인트라넷 응용 프로그램입니다. 이 템플릿은 응용 프로그램 사용자를 인증할 수 있도록 보통 Windows 통합 인증을 사용합니다. 해당 메커니즘은 네트워크 수준에서 작동하며, 응용 프로그램 자체에 인증 논리를 추가하지 않아도 인트라넷에 게시된 모든 서비스에 적용됩니다.

클라우드 응용 프로그램과 같이 인트라넷 외부에 응용 프로그램을 배포하는 경우에는 네트워크 수준 인증을 더 이상 사용할 수 없습니다. 이러한 경우 인증을 처리하기 위한 가장 일반적인 전략으로는 응용 프로그램 전면에 일종의 미들웨어를 추가하는 방법이 있습니다. 그러면 필요한 인증 확인 기능이 상위 수준에 다시 작성됩니다. 이 추가 계층에서는 인증되지 않은 요청 가로채기, 인증 프로토콜 적용, 응용 프로그램 외부에서 인증하도록 사용자 리디렉션, 인증된 사용자에 대한 정보를 응용 프로그램에 반환, 세션 관리 그리고 일반적으로 액세스 제어에 필요한 모든 작업을 처리할 수 있습니다.

이 전략은 업계에서 사용되는 모든 플랫폼, 개발 스택 및 로그온 프로토콜에 걸쳐 일관되게 적용됩니다. 전송되는 정보와 프로그래밍 모델은 달라질 수 있지만 일반적인 패턴은 대개 동일합니다.

이 연습에서는 WS-Federation 프로토콜을 통해 응용 프로그램을 Azure AD에 연결합니다. 이 방식은 웹 SSO를 구현하기 위해 선택할 수 있는 옵션 중 하나일 뿐이며 SAML-P 등의 기타 방식을 선택할 수도 있습니다.

.NET Framework 4.5에서는 WS-Federation이 기본적으로 지원됩니다. ASP.NET 응용 프로그램 컨텍스트에서 프로토콜 흐름을 적용하고 인증과 세션을 처리하는 데 필요한 모든 클래스가 기본적으로 포함되어 있습니다.

간략하게 설명하자면, .NET 4.5에서는 응용 프로그램의 HTTP 파이프라인에서 인스턴스화되는 HttpModule 집합을 제공합니다. 이러한 모듈은 널리 알려진 구성 섹션을 참조하도록 설계되어 있습니다. 이 섹션에는 응용 프로그램과 인증 기관(여기서는 Azure AD 테넌트)의 프로토콜 정보를 모두 포함합니다. 요청이 들어오면 모듈은 요청을 검사한 다음 적절한 인증 프로토콜을 적용합니다. 예를 들어 인증되지 않은 요청이 수신되면 모듈은 구성에서 Azure AD 테넌트의 정보를 읽고 사용하여 WS-Federation 로그인 메시지를 작성합니다. 그런 다음 Azure AD에 인증할 수 있도록 사용자를 자동으로 리디렉션하는 데 해당 메시지를 사용합니다.

note참고
.NET Framework 4.5의 클레임 기반 ID 관련 작업 전용 클래스 하위 집합을 WIF(Windows Identity Foundation)라고 합니다. 이전 버전 프레임워크(3.5 및 4.0)를 대상으로 하는 응용 프로그램에서도 독립 실행형 라이브러리로 별도 출시된 이전 버전 WIF를 사용하여 이 연습에서 설명하는 단계를 구현할 수 있습니다. 해당 WIF는 여기서 다운로드할 수 있습니다. 그러나 두 버전이 완전히 호환되지는 않으므로(클래스가 서로 다른 네임스페이스에서 활성화됨) 단계별 지침은 달라질 수 있으며, 개별 Visual Studio 버전에 맞는 도구(2008 및 2010, 여기서 다운로드)를 사용해야 합니다.

Visual Studio 2012에서는 웹 로그온에 WS-Federation을 사용하도록 응용 프로그램을 구성할 수 있는 가리킨 다음 클릭 방식 도구가 제공됩니다. 이 도구의 UI를 사용하여 인증용으로 신뢰할 기관에 대한 몇 가지 주요 정보를 입력하면 해당하는 구성 항목이 생성됩니다. 이 연습에서는 해당 도구가 대부분의 코드를 자동으로 생성하므로 직접 작성해야 하는 코드는 거의 없습니다.

  1. 지금까지 웹 로그온을 구현하는 방법을 살펴보았습니다. 이제 ID 및 액세스 도구를 사용하여 응용 프로그램을 구성하겠습니다. 솔루션 탐색기에서 응용 프로그램 프로젝트를 마우스 오른쪽 단추로 클릭하고 상황에 맞는 메뉴에서 ID 및 액세스...를 클릭합니다.

    ID 및 액세스 그러면 Visual Studio에서 아래와 같은 대화 상자가 표시됩니다.

    ID 및 액세스 공급자 모든 작업은 현재 표시되어 있는 공급자 탭에서 수행합니다. 이 연습에서는 수행하려는 작업에 필요하지 않은 모든 옵션을 무시합니다.

  2. 도구에는 인증을 아웃소싱하는 데 사용할 수 있는 여러 기관 유형이 나열됩니다. 이 연습에서는 비즈니스 ID 공급자를 사용할 것이므로 해당 항목(위에서 두 번째 옵션)을 클릭합니다.

    ID 및 액세스 구성 이 옵션을 선택하면 해당 UI 요소가 아래쪽 패널에 표시됩니다. 이러한 컨트롤이 요청하는 정보는 이전 섹션에서 설명한 응용 프로그램 등록 프로세스 종료 시 표시되는 항목과 정확하게 일치합니다. 입력해야 하는 정보(맨 아래 항목부터)는 다음과 같습니다.

    • 응용 프로그램의 앱 ID URI(영역) 입력: 등록 중에 정의한 응용 프로그램의 식별자입니다. 관리 포털이 표시된 브라우저 창으로 다시 전환하여 앱 ID URI로 코드 업데이트 필드에서 해당 값을 복사한 다음 여기에 붙여 넣으십시오.

    • STS 메타데이터 문서의 경로 입력: "STS 메타데이터 문서"는 컴퓨터에서 읽을 수 있는 연결 대상 기관 설명이 포함된 파일입니다. 도구는 해당 설명을 사용하여 로그온 흐름에 반드시 필요한 매개 변수의 값을 결정합니다(자세한 내용은 뒷부분에서 설명함). 모든 Azure AD 테넌트는 이러한 문서 하나를 표시하며 해당 위치는 등록 프로세스 완료 시 제공됩니다. 관리 포털로 전환하여 응용 프로그램 등록 페이지에서 해당 값을 복사한 다음 도구로 다시 전환하여 이 필드에 경로를 붙여 넣으십시오.

      note참고
      메타데이터 문서의 경로를 텍스트 상자에 붙여 넣으면 인증서가 잘못되었다는 경고가 표시됩니다. 이 경고는 메타데이터 문서가 자체 서명 인증서로 서명되었기 때문에 표시되며 문제가 있다는 의미는 아닙니다.

    확인을 누릅니다. 도구가 지정한 메타데이터 문서에 연결하여 기관의 정보(로그온에 사용할 끝점 주소, 인증 토큰 서명 확인에 사용할 X.509 인증서, 발급된 인증 토콘의 형식/버전 등)를 읽은 다음 응용 프로그램을 Azure AD에 연결하는 데 필요한 항목을 생성하여 web.config에 추가하는 데 사용합니다.

다음 목록에서는 도구가 web.config에 추가하는 기본 항목에 대해 설명합니다. 자세한 설명은 문서의 고급 섹션을 참조하십시오.

  • system.identityModel 및 system.identityModel.services에 대한 <section> 항목: 구성에서 ID별 구성 설정을 파악하는 데 필요합니다.

  • <system.web>의 <authorization> 설정: 도구는 응용 프로그램에 대한 모든 요청을 인증해야 하도록 기존 ASP.NET 인증 설정을 자동으로 변경합니다. 이 과정에서는 "블랭킷 리디렉션"이라는 동작이 적용됩니다. 인증되지 않은 사용자도 응용 프로그램의 일부분을 사용할 수 있는 방식과는 달리, 이 동작이 적용되면 인증되지 않은 모든 요청이 인증 기관으로 리디렉션됩니다. 사용자가 기관에 이미 로그인되어 있으면 대개 인증이 자동으로 수행되는 LOB 응용 프로그램에서는 이러한 동작이 기본적으로 사용됩니다. 사례별로 인증 요구 사항을 제공하기 위해 이 동작을 변경하려는 개발자는 <authorization> 설정만 변경하면 됩니다.

  • <system.webServer/modules>의 FAM(WSFederationAuthenticationModule) 및 SAM(SessionAuthenticationModule): 이러한 항목은 WS-Federation을 사용한 인증을 처리하는 HttpModule을 응용 프로그램의 HTTP 파이프라인에 추가합니다. FAM은 프로토콜 적용을 담당하는 모듈로, 로그온 요청, 토큰 유효성 검사 및 로그아웃 관리 흐름을 주로 처리합니다. SAM은 세션을 처리하며, 구체적으로는 세션 쿠키를 생성하고 쿠키의 유효성을 검사하며 모든 요청에 쿠키가 포함되도록 적용하고 세션 길이를 처리하는 등의 작업을 수행합니다. 이러한 항목의 동작은 아래에서 설명하는 config 요소에 의해 결정됩니다.

  • <system.identitymodel/identityConfiguration> 섹션: 이 요소는 인증 단계 중의 응용 프로그램 동작을 결정합니다. 예를 들면 다음과 같습니다. 이 요소는 인증 서비스를 제공하는 것으로 신뢰되는 기관의 이름과 이러한 기관이 서명에 사용하는 인증서를 기록하여 해당 기관의 목록을 하위 요소 ValidatingIssuerNameRegistry에 저장합니다.

  • <system.identitymodel.services/federationConfiguration> 섹션: 이 섹션에서는 WS-Federation 흐름을 진행하는 데 필요한 정보를 제공합니다. 이러한 정보에는 로그온 요청에 사용할 기관의 주소, 요청에 포함할 응용 프로그램 자체의 식별자 등이 있습니다.

웹 로그온에 Azure AD를 활용하려면 자동으로 생성된 구성만 있으면 되며, 응용 프로그램 자체에서 인증 관련 코드를 작성할 필요는 없습니다. 사용자 ID 정보에 액세스하려는 경우에는 현재 계정에서 클레임을 쿼리하면 됩니다. 예를 들어 현재 사용자의 이름과 성에 액세스하려는 경우 인증이 수행된 방식을 확인할 필요 없이 다음 코드를 사용하면 됩니다.

//...
using System.Security.Claims;

namespace ExpenseReport.Controllers
{
  public class HomeController : Controller
  {
    public ActionResult Index()
    {            
      ClaimsPrincipal cp = ClaimsPrincipal.Current;
      string fullname = 
             string.Format("{0} {1}", cp.FindFirst(ClaimTypes.GivenName).Value,
             cp.FindFirst(ClaimTypes.Surname).Value);
      ViewBag.Message = string.Format("Dear {0}, welcome to the Expense Note App", 
                        fullname);
      return View();
     }
//...

.NET 4.5부터는 .NET의 모든 ID가 ClaimsPrincipal과 함께 제공됩니다. 여기서는 Azure AD에서 생성한 인증 토큰의 유효성을 검사하는 동안 현재 ClaimsPrincipal이 생성되었으며, 사용자가 로그온할 때 해당 ClaimsPrincipal을 제공합니다.

모든 ClaimsPrincipal에는 클레임, 즉 사용자를 인증한 기관에서 어설션한 현재 사용자를 설명하는 특성 컬렉션이 포함되어 있습니다. 이 연습에서는 Azure Active Directory가 토큰을 통해 계정의 클레임을 발급합니다. 사용 가능한 클레임의 전체 목록은 온라인 설명서를 참조하십시오.

Azure AD는 인증된 사용자에 대해 고정 클레임 집합을 발급합니다. 아래 표에서 Azure AD에서 사용할 수 있는 모든 클레임을 빠르게 참조할 수 있습니다. 전체 설명은 설명서에서 확인 가능합니다.

 

Type 샘플의 값 설명

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

S40rgb3XjhFTv6EQTETkEzcgVmToHKRkZUIsJlmLdVc

현재 응용 프로그램에 대해 인증된 사용자에게 지정된 변경/재사용 불가능한 고유 식별자

http://schemas.microsoft.com/identity/claims/objectidentifier

528b2ac2-aa9c-45e1-88d4-959b53bc7dd0

디렉터리의 사용자에 대한 식별자. 사용자에 대한 디렉터리 쿼리 수행 시 유용합니다.

http://schemas.microsoft.com/identity/claims/tenantid

cab1a5ac-f33b-45fa-9bf5-f37db0fed422

디렉터리 테넌트의 식별자

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

John

사용자의 이름

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

user@test04-realm2

사용자의 UPN

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Doe

사용자의 성

http://schemas.microsoft.org/identity/claims/identityprovider

https://sts.windows.net/cab1a5ac-f33b-45fa-9bf5-f37db0fed422/

웹 로그온 프로토콜에 표시되는 사용자를 인증한 기관의 ID(여기서는 WS-Federation)

이제 응용 프로그램에는 Azure AD를 사용한 웹 로그온을 수행하는 데 필요한 모든 조건이 갖춰졌습니다. 그러나 아직 응용 프로그램 준비 단계가 완료된 것은 아닙니다. 최소한 두 가지 주요 기능을 더 추가해야 합니다. 이 두 가지 기능은 로그아웃 지원 및 기관 프로토콜 정보 자동 새로 고침입니다.

다음 두 섹션에서 이러한 두 기능을 추가하는 방법을 자세히 설명합니다. "응용 프로그램 실행" 섹션으로 진행하기 전에 해당 섹션의 작업도 수행하는 것이 좋습니다.

현재 사용되고 있는 웹 로그온 프로토콜에는 분산 로그아웃 작업을 수행하기 위한 프로비전이 포함되는 경우가 많습니다. 분산 로그아웃 작업 흐름에서는 현재 응용 프로그램이 현재 사용자 세션을 취소할 뿐 아니라, 기관에 연결하여 동일 기관에서 설정했을 수 있는 기타 모든 응용 프로그램 세션에 로그아웃 명령을 전파해야 함을 알립니다. WS-Federation 역시 WIF의 개체 모델에서 완전하게 구현되는 전체 로그아웃 흐름을 제공합니다. 이 하위 섹션에서는 샘플 응용 프로그램에 분산 로그아웃 기능을 추가하는 방법을 설명합니다. 이 과정에서는 로그아웃 흐름을 트리거하는 데 적합한 연결을 사용자 환경에 제공하고, Azure AD 테넌트에 대해 설정할 적절한 로그아웃 메시지를 생성합니다.

  1. 먼저 응용 프로그램에 SignOut 컨트롤러를 추가합니다. 이 작업은 솔루션 탐색기에서 프로젝트 아래의 컨트롤러 폴더를 찾아 마우스 오른쪽 단추로 클릭하고 추가, 컨트롤러를 차례로 클릭하면 쉽게 수행할 수 있습니다. 해당 컨트롤러의 이름을 SignOutController로 지정하고 빈 MVC 컨트롤러(보통 기본 설정임)를 선택한 후에 추가를 클릭합니다.

  2. 일부 새 어셈블리의 클래스를 사용해야 하므로 해당 클래스에 대한 참조를 추가해야 합니다. 마찬가지로 솔루션 탐색기에서 참조 노드를 마우스 오른쪽 단추로 클릭하고 참조 추가...를 선택한 다음 검색 어셈블리 필드에 system.identitymodel.services를 입력하고 주 목록에서 해당 어셈블리를 선택합니다. 확인을 누릅니다.

  3. 새로 만든 SignOutController.cs 파일로 돌아갑니다. using 지시문에 다음 항목을 추가합니다.

    using System.IdentityModel.Services;
    using System.IdentityModel.Services.Configuration;
    
    다음으로 SignOutController 클래스의 구현을 다음과 같이 변경합니다.

    public ActionResult Index()
    {
        return View("SignOut");
    }
    
    public void SignOut()
    {
         WsFederationConfiguration fc = 
                FederatedAuthentication.FederationConfiguration.WsFederationConfiguration;
    
         string request = System.Web.HttpContext.Current.Request.Url.ToString();
         string wreply = request.Substring(0, request.Length - 7);
    
         SignOutRequestMessage soMessage = 
                         new SignOutRequestMessage(new Uri(fc.Issuer), wreply);
         soMessage.SetParameter("wtrealm", fc.Realm);
    
         FederatedAuthentication.SessionAuthenticationModule.SignOut();
         Response.Redirect(soMessage.WriteQueryString());
    } 
    
    
    아래에서 해당 코드가 수행하는 작업에 대해 간략하게 설명합니다.

    • 첫 번째 메서드인 Index()https://localhost:44341/SignOut 형식의 요청을 처리합니다. 연습 뒷부분의 몇 단계에서 이 뷰의 주소를 추가합니다. 이 주소는 로그아웃 성공을 알리기 위한 것이며 다음 메서드에서 그러한 용도로 사용됩니다.

    • SignOut() 메서드는 https://localhost:44341/SignOut/SignOut 형식의 요청을 처리하며 주 로그아웃 논리를 포함합니다.

    • 첫 번째 줄은 WIF가 web.config의 WS-Federation 설정을 추적하는 데 사용하는 개체를 검색합니다. 현재 응용 프로그램에 맞게 로그아웃 메시지를 작성하려면 해당 개체가 필요합니다.

      note참고
      일반적으로는 하드 코딩된 값을 참조하거나 사용자 지정 저장소에서 값을 가져오는 대신 구성 값을 참조하면 코드를 나머지 프로토콜 설정에 맞게 조정할 수 있으므로 효율적입니다. 배포 전후에 구성 파일에서 설정이 변경된 횟수에 관계없이 논리는 계속 작동합니다.

    • 두 번째와 세 번째 줄은 기관에서 로그아웃 흐름 종료 시 사용하도록 할 반환 주소를 만듭니다. 여기서는 해당 주소가 앞에서 설명한 뷰를 가리키도록 지정합니다. 이렇게 하면 코드가 현재 요청의 URL을 가져온 다음 후행 'SignOut'을 제거합니다. 이처럼 요청에서 주소를 파생시키면 해당 주소가 클라이언트에 대해 올바르게 확인됩니다. 반면 호스팅 계층에서 주소를 가져오면 부하 분산 장치 사용 시 내부 포트 문제가 발생할 수 있습니다.

    • 네 번째 줄에서는 WIF를 사용하여 WS-Federation 로그아웃 메시지를 작성하고 이전 줄에서 정의한 반환 주소 및 기관 URL을 전달합니다. 이 메시지는 연결 형식으로도 직접 쉽게 작성할 수 있지만 WIF 개체 모델을 사용하면 보다 간략한 코드를 작성하고 대부분의 구분 세부 정보를 무시할 수 있습니다. 로그아웃 메시지의 모양을 확인하려면 이후 섹션에서 응용 프로그램을 실행할 때 HTTP 추적을 캡처하거나 여기에 나와 있는 사양을 참조하십시오.

    • 네 번째 줄은 <wsFederation> 구성 요소의 realm 특성에 기록된 현재 응용 프로그램의 식별자를 메시지에 추가합니다.

    • 다섯 번째 줄은 앞에서 자동 생성 구성을 설명할 때 나왔던 SAM을 사용하여 로컬 세션을 정리합니다. 이때 로그온 시 생성된 세션 쿠키를 삭제하고 필요할 수 있는 로컬 리소스 정리를 수행합니다.

      note참고
      이 문서에서 설명하는 샘플 응용 프로그램은 많은 작업을 수행하지 않지만 실제 응용 프로그램은 사용자 세션 중에 리소스를 할당할 수 있습니다. 이러한 경우에는 Global.asax 파일에 해당 이벤트 처리기를 추가해 세션을 닫을 때 삭제해야 하는 리소스를 정리하는 방식으로 SAM의 SigningOutSignedOut 이벤트를 활용할 수 있습니다.

여기서 사용하는 뷰는 매우 단순합니다. 앞에서도 언급한 것처럼 이 뷰는 단지 로그아웃 흐름용으로 의미 있는 반환 지점을 만들기 위한 것입니다.

  1. 솔루션 탐색기에서 노드를 마우스 오른쪽 단추로 클릭하고 SignOut 폴더를 추가합니다.

  2. 해당 폴더를 마우스 오른쪽 단추로 클릭하고 추가, 를 차례로 클릭하여 뷰를 추가합니다. 새 뷰의 이름도 SignOut으로 지정합니다. 로그아웃이 수행되었음을 나타내도록 뷰 파일(SignOut.cshtml)에 자리 표시자 표시 코드를 추가합니다. 예를 들면 다음과 같습니다.

    @{
        ViewBag.Title = "SignOut";
    }
    
    <h2>You have successfully signed out</h2>
    
  3. 이전 섹션에서 블랭킷 리디렉션을 통해 인증을 처리하도록 응용 프로그램을 구성했습니다. 따라서 정상적으로 로그아웃한 후 이 뷰에 액세스하려고 하면 다시 로그인해야 하도록 Azure AD로 즉시 리디렉션됩니다. 이 동작을 방지하려면 web.config<location> 요소를 사용하여 인증 정책에 대한 예외 하나를 만들면 됩니다.

    첫 번째 <system.web> 요소를 찾은 다음 바로 위에 다음 코드 조각을 붙여 넣습니다.

      <location path="SignOut">
        <system.web>
          <authorization>
            <allow users="*" />
          </authorization>
        </system.web>
      </location>
    
    
    이 코드는 인증되지 않은 사용자를 포함한 모든 사용자가 SignOut 경로에 액세스할 수 있음을 ASP.NET에 알립니다. 이와 같이 코드를 작성하면 정상적으로 로그아웃한 후에도 브라우저에서 이 뷰가 렌더링됩니다.

  1. 이제 응용 프로그램에 로그아웃 기능을 추가했으므로 사용자 환경에 해당 기능을 표시하기만 하면 됩니다. 이 작업은 매우 간단하게 수행할 수 있습니다. 솔루션 탐색기의 Views\Shared 경로에서 _layout.cshtml을 엽니다. 그런 다음 "Hello" 문자열을 검색하여 일반적인 MVC 4 레이아웃 맨 위에 로그인 정보를 렌더링하는 코드를 찾아서 로그인 섹션을 다음과 같이 수정합니다.

    <section id="login">
      @if (Request.IsAuthenticated)
      {  
        <text> Hello, <span class="username">@User.Identity.Name</span>! 
      @Html.ActionLink("Signout","SignOut", "SignOut")</text>
      }
      else {
        <text>  You are not authenticated </text>
      }
    </section> 
    
    

그러면 로그인된 사용자에게 표시되는 인사말 오른쪽에 로그아웃 명령이 추가되므로 모든 뷰에서 로그아웃 작업을 트리거할 수 있습니다.

지금까지 ID 및 액세스 도구를 사용하여 응용 프로그램이 선택한 Azure AD 테넌트로부터 들어오는 토큰을 수락하도록 구성했습니다. 도구는 이를 위해 지정된 Azure AD 끝점에 연결하는 데 필요한 프로토콜 정보를 web.config에 캐시합니다. 또한 들어오는 토큰이 실제로 Azure AD 테넌트에서 생성된 것인지 유효성을 검사하기 위해 인증 시에 사용된 주요 정보를 저장합니다. 이러한 정보에는 테넌트를 나타내는 발급자 이름과 토큰 서명을 확인하는 데 사용해야 하는 공개 키(X.509 인증서 형식)가 포함됩니다.

일반적인 보안 방식에서는 암호화 키를 정기적으로 갱신하며, Azure AD 서명 키도 마찬가지입니다. 오래된 키는 고정된 시간 간격에 따라 폐기되고 발급자의 서명 논리 및 테넌트의 메타데이터 문서에 새 키가 추가됩니다. 긴급 상황에서는 경고를 거의 또는 전혀 표시하지 않고 키가 즉시 갱신될 수 있습니다.

서명 키가 제공될 때마다 응용 프로그램 설정을 적절하게 변경해야 합니다. 지금까지 수행한 연습의 방식에 따르면 도구를 다시 실행하여 새 메타데이터 문서를 읽은 다음 web.config 항목을 새로 고쳐야 합니다.

가동 중지 시간을 최소화하려면 자동 복구 논리를 응용 프로그램에 직접 추가하는 것이 좋습니다. 이렇게 하면 운영자의 개입 없이도 메타데이터 문서를 프로그래밍 방식으로 사용하고 키 제공 시 적절하게 대응할 수 있습니다. 아래에는 이러한 기능을 구현하는 방법의 예가 나와 있습니다.

  1. 이 문서의 앞부분에서 설명한 것처럼 솔루션 탐색기를 사용하여 System.IdentityModel 어셈블리에 대한 참조를 추가합니다.

  2. Global.asax 파일에 다음 using 지시문을 추가합니다.

    using System.Configuration;
    using System.IdentityModel.Tokens;
    
    
  3. 그런 후에 다음 메서드를 Global.asax 파일에 추가합니다.

    //...
    protected void RefreshValidationSettings()
    {
        string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config";
        string metadataAddress = 
                      ConfigurationManager.AppSettings["ida:FederationMetadataLocation"];
        ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath);
    }
    
    
    여기에 나와 있는 논리는 매우 단순합니다. ValidatingIssuerNameRegistry는 ID 및 액세스 도구가 신뢰할 기관 및 해당 기관에서 발급하는 토큰을 확인하는 데 사용할 키에 대한 정보를 기록하는 데 사용하는 클래스입니다. WriteToConfig는 메타데이터 문서에서 발급자 설정(여기서는 도구를 처음 실행할 때 메서드의 두 번째 줄을 통해 저장된 구성에서 검색됨)을 읽은 다음, 해당 설정을 사용하여 지정된 경로(메서드 첫 번째 줄의 현재 AppDomain에서 생성됨)에서 파일의 해당 구성 섹션을 만들거나 업데이트하는 정적 메서드입니다.

  4. RefreshValidationSettings()를 응용 프로그램 수명 주기에 삽입하려면 아래와 같이 Application_Start()에서 호출합니다.

    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
    
        WebApiConfig.Register(GlobalConfiguration.Configuration);
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        RefreshValidationSettings();
    }
    
    Application_Start에서 RefreshValidationSettings를 호출하면 안전한 시간에 web.config가 수정됩니다. 반면 응용 프로그램 수명 주기의 뒷부분에서 이 호출을 수행하면 새로 고침이 트리거될 위험이 있습니다.

Important중요
응용 프로그램에서 유효성 검사 키를 자동으로 새로 고칠 때는 몇 가지 추가적인 사항에 주의해야 합니다. 가장 먼저 완화해야 하는 위협은 공격자가 맬웨어를 통해 사용자를 악성 메타데이터 문서로 이동시킨 다음 응용 프로그램이 잘못된 키를 신뢰하도록 하는 DNS 하이재킹입니다.

HTTP 요청 처리를 위한 .NET 기본값을 재정의하지 않으면 메타데이터 문서는 HTTPS 끝점에서 호스팅되므로 위의 시나리오는 자동으로 방지됩니다. DNS 하이재킹에서는 요청을 악의적인 끝점으로 리디렉션할 수 있지만 그러한 끝점은 HTTPS 서버 유효성 검사를 통과할 수 없습니다. 공격자는 메타데이터 문서가 호스팅되는 도메인을 실제로 소유하고 있지 않으므로 해당 도메인에 대해 발급된 인증서를 확보할 수 없습니다. 따라서 클라이언트는 서버의 문제를 감지하여 잘못된 이동을 차단할 수 있습니다.

일부 개발 시나리오에서는 대개 ServicePoint 클래스를 통해 HTTPS 유효성 검사를 해제해야 하는 경우도 있습니다. 이 섹션에서 설명하는 자동 메타데이터 새로 고침 논리를 사용하는 경우에는 응용 프로그램을 프로덕션 환경에 배포하기 전에 HTTPS 유효성 검사 설정을 반드시 복원해야 합니다.

  1. 이제 응용 프로그램의 실제 작동 방식을 확인할 수 있습니다. F5 키를 누릅니다. 그러면 브라우저 창이 열리고 프로젝트 설정의 "MVC 응용 프로그램 만들기" 섹션에 지정된 URL 액세스를 시도합니다.

    처음에는 인증서 오류가 표시됩니다. 이는 정상적인 동작이므로 이 웹 사이트를 계속 탐색합니다(권장하지 않음).를 클릭합니다. 프로덕션 응용 프로그램에서는 이 오류를 무시하면 안 되지만 이 연습에서는 무시해도 됩니다.

    인증서 오류 주소 표시줄에 응용 프로그램 URL이 잠시 동안 표시될 수 있습니다. 그러나 응용 프로그램 전면의 FAM 모듈이 해당 호출을 인증되지 않은 것으로 즉시 인식하여 구성에서 수행해야 하는 작업을 읽은 다음 Azure AD로의 로그인 리디렉션을 트리거합니다. 그러면 URL 주소 표시줄에 기관의 주소가 대신 표시되며 사용자에게는 Azure AD UI를 통해 인증하라는 메시지가 표시됩니다.

    note참고
    처음에 Microsoft 계정을 사용하여 관리 포털에 로그인한 경우에는 앞에서 만든 새 사용자 계정을 사용하여 Azure 구독을 관리할 수 없습니다. 새 사용자로 응용 프로그램에 로그인한 후 관리 포털로 돌아가려고 하면 오류 메시지가 표시됩니다. 이 경우에는 디렉터리 테넌트를 만드는 데 사용한 계정을 대신 사용하여 관리 포털에 로그인해야 합니다. 처음에 Azure AD 계정을 사용하여 관리 포털에 로그인했으며 앞에서 만든 새 사용자에게 전역 관리자 역할을 부여한 경우에는 해당 새 사용자가 Azure 구독을 관리할 수 있습니다.

    AAD에 로그인
  2. 연습의 첫 섹션에서 Azure 테넌트에서 만든 사용자의 자격 증명을 입력하고 로그인 단추를 누릅니다.

    Azure AD 테넌트에서 사용자를 만들 때는 관리 포털에서 해당 사용자에게 임시 암호를 할당합니다. 이 암호를 사용하여 인증을 해야 합니다. 그러나 이러한 암호는 임시용이므로 첫 번째 로그인 작업 중에 적절한 사용자 암호를 선택하라는 메시지가 표시됩니다. 이때 암호를 선택해야 인증 흐름을 계속 진행할 수 있습니다. 암호를 선택하고 나면 응용 프로그램에 대한 일반 로그인 흐름이 다시 진행됩니다.

    응용 프로그램 홈 페이지 인증이 정상적으로 완료되면 WIF가 들어오는 인증 토큰의 클레임을 처리합니다. 이러한 클레임은 홈 컨트롤러에 추가했던 간단한 표시 코드에 사용됩니다. 이제 다시 인증하지 않아도 사이트를 탐색할 수 있습니다. 모든 포스트백에는 SAM 모듈이 처리한 세션 쿠키가 포함됩니다.

  3. 세션 종료 시 수행되는 작업을 확인하려면 오른쪽 위의 로그아웃 링크를 클릭합니다. 그러면 앞에서 코딩한 리디렉션이 수행되어 최종적으로는 아래 뷰가 표시됩니다.

    로그아웃 실제로 로그아웃되었는지 확인하려면 다른 UI 요소를 클릭해 봅니다. 그러면 인증 주기가 다시 시작됩니다.

이 문서의 연습 부분에서는 웹 응용 프로그램에 웹 로그온 기능을 추가하기 위해 수행해야 하는 필수 단계에 대해 설명했습니다. 문서의 나머지 부분에서는 일부 주요 항목에 대해 기본적인 사항보다 좀 더 자세한 설명을 제공하고, 응용 프로그램을 보다 높은 수준으로 활용하기 위해 수행해야 할 수 있는 몇 가지 기타 작업에 대해 다룹니다.

이 섹션에서는 응용 프로그램을 Azure 웹 사이트에서 배포 및 실행하기 위해 해당 설정을 수정하는 방법을 설명합니다. 응용 프로그램 자체는 거의 변경되지 않으며, 응용 프로그램의 새 주소와 세션 관리 부분만 조정하면 됩니다.

문서의 이 부분에서는 응용 프로그램 배포 대상으로 사용할 Azure 웹 사이트를 만들어야 합니다. 사용 가능한 웹 사이트가 이미 있는 경우에는 사용하면 되고, 없는 경우에는 이 문서에서 Azure 웹 사이트를 만들고 게시하는 방법을 확인할 수 있습니다. 해당 문서의 자습서 내용에 따라 웹 사이트를 만드는 경우에는 게시 프로필 다운로드 직후에 작업을 중지하십시오. 응용 프로그램 배포 전에 두 가지 사항을 조정해야 합니다.

Azure 관리 포털에서 응용 프로그램 설정 조정

응용 프로그램 등록 섹션에서 설명한 것처럼, Azure AD UI에서 응용 프로그램을 정의하는 데 사용되는 주요 매개 변수 중 하나는 응용 프로그램 자체의 URL입니다. 지금까지 설명한 연습 단계에서는 로컬 IIS Express를 응용 프로그램 위치로 가정했습니다. 그러나 Azure 웹 사이트에 배포하는 경우에는 응용 프로그램 URL이 변경되므로 Azure AD의 설정에도 해당 변경 내용을 반영해야 합니다.

  1. 관리 포털로 돌아가서 왼쪽의 Active Directory 탭을 선택하고 디렉터리 테넌트를 클릭한 다음 응용 프로그램 헤더를 선택합니다. 그런 다음 사용 중인 응용 프로그램에 해당하는 항목을 클릭합니다. 구성 헤더를 클릭하면 작성 시 입력한 응용 프로그램 설정을 수정할 수 있는 화면으로 이동됩니다. 이 자습서에서는 화면 위쪽 영역을 무시하고 아래쪽의 Single Sign-On 섹션으로 스크롤합니다.

    Single Sign-On
  2. 회신 URL 텍스트 상자를 찾아서 대상 Azure 웹 사이트의 주소를 https://aadga.windowsazure.net/과 같이 입력합니다. 그러면 인증 성공 시 Azure AD가 스레드 앞부분에서 사용한 개발 시 위치가 아닌 Azure 웹 사이트 위치로 토큰을 반환합니다. 값을 업데이트한 후 화면 아래쪽의 명령 모음에서 저장을 클릭합니다.

note참고
앱 ID URI에는 문서의 앞부분에서 만든 로컬 호스트 기반 값이 계속 사용되고 있습니다.

기술적으로는 식별자가 URI 형식이며 현재 디렉터리 테넌트의 모든 응용 프로그램에서 고유하기만 하면 여기서 설명하는 유형의 응용 프로그램에 대해 어떤 값이라도 사용 가능합니다. 따라서 기본 지침에는 해당 값을 업데이트하는 방법이 포함되어 있지 않습니다.

그러나 손쉬운 관리를 위해 응용 프로그램을 보다 명확하게 나타내는 값으로 앱 ID URI를 수정할 수 있습니다. 이러한 값의 일반적인 예로는 회신 URL 값에서 파생된 값을 들 수 있습니다.

앱 ID URI 값을 변경하는 경우 응용 프로그램을 배포하기 전에 보다 포괄적인 변경 내용을 적용해야 합니다. 자세한 내용은 뒷부분에서 설명합니다.

Azure 웹 사이트에서 실행하도록 응용 프로그램 준비

대부분의 웹 로그온 구성은 클라우드에서 즉시 사용 가능합니다. 단, Azure 웹 사이트의 기능과 관련하여 적용해야 하는 한 가지 변경 내용이 있습니다.

웹 로그온 프로세스를 수행하면 세션 쿠키가 만들어져 인증 시점부터 모든 요청에서 전송됩니다. 세션 쿠키는 WIF 미들웨어에 의해 작성되며 클라이언트가 권한 상승을 위해 클레임 목록을 변경하는 등의 용도로 남용하지 못하도록 기본적으로 DPAPI를 통해 서명 및 암호화됩니다(배경 정보는 이 문서 참조). 그러나 Azure 웹 사이트의 IIS 설정은 세션 보호를 위한 DPAPI 사용을 차단하므로 WIF가 관련 쿠키를 보호하는 방식을 변경해야 합니다. .NET Framework 4.5에서는 이를 위한 대체 기능을 기본적으로 제공합니다. 이 기능은 MachineKey(여기서 설명서 참조)를 활용하며, Azure 웹 사이트에서도 문제 없이 작동합니다.

ID 및 액세스 도구를 사용하면 이 변경을 매우 간편하게 수행할 수 있습니다.

  1. 솔루션 탐색기에서 프로젝트를 마우스 오른쪽 단추로 클릭하고 ID 및 액세스...를 선택한 다음 구성 탭을 선택합니다. 그러면 다음 스크린샷과 같은 화면이 표시됩니다.

    ID 및 액세스 Azure 웹 사이트
  2. 웹 팜 사용 가능 쿠키 사용 플래그를 선택하고 확인을 누릅니다. 그러면 web.config에서 필요한 요소가 자동으로 추가되어 쿠키 보호 방법이 MachineKey로 전환됩니다. 실제 환경에서는 기본 클래스인 SessionSecurityTokenHandlerMachineKeySessionSecurityTokenHandler로 바꿉니다.

    note참고
    이전 단계에서 Azure 관리 포털의 앱 ID URI를 변경한 경우 이 UI를 사용하여 프로젝트에 해당 변경 내용을 쉽게 적용할 수 있습니다. 위쪽의 두 텍스트 필드에 앱 ID URI 값을 붙여 넣은 다음 확인을 누르면 됩니다. 그러면 해당 변경 내용이 구성 파일의 적절한 위치에 적용됩니다.

    원하는 경우 web.config 파일의 <system.web> 섹션에 <customErrors mode="Off" />를 추가하여 ASP.NET 사용자 지정 오류 메시지 표시를 일시적으로 해제할 수 있습니다. 그러면 배포 시에 발생하는 문제를 해결할 수 있습니다. 그러나 프로덕션 환경으로 이동하기 전에 해당 기능을 다시 설정해야 합니다. 공격자가 자세한 오류 메시지를 사용하여 응용 프로그램을 열 수 있는지를 검색할 가능성이 있는데, customError를 사용하면 그러한 공격을 방지할 수 있습니다.

이제 Azure 웹 사이트에서 응용 프로그램을 실행하기 위한 준비가 완료되었습니다. 다음으로는 게시 설정을 사용하여 응용 프로그램을 배포하고 브라우저를 연 다음, 응용 프로그램의 azurewebsite.net 주소로 이동하여 연습의 응용 프로그램 테스트 섹션에서 설명한 것과 같은 흐름을 따르면 됩니다. 여기서는 모든 사용자 지정 논리를 위치에 독립적으로 설계했으므로 온-프레미스에서도 동일한 작업을 수행할 수 있습니다.

ID 및 액세스 도구는 WS-Federation을 통해 응용 프로그램을 Azure AD 테넌트와 통합하는 데 필요한 구성 설정을 자동으로 생성합니다. 이러한 설정을 전혀 확인할 필요가 없는 것이 가장 좋습니다. 그러나 기본 동작을 변경하거나 문제를 해결해야 하는 경우도 있습니다. 이러한 경우에는 WIF 구성 설정을 확인하면 됩니다.

웹 로그인 흐름에 사용되는 WIF 클래스와 메서드에 대한 전체 설명은 MSDN에 나와 있습니다. 여기서는 ID 및 액세스 도구를 통해 수정한 후 주석 처리된 web.config 버전을 살펴봅니다. 편의상 이 버전에는 Azure 웹 사이트로 게시하는 섹션에서 적용한 변경 내용도 포함되어 있습니다.

note참고
이 문서에는 명확한 설명을 위해 전체 Web.config 소스가 포함되어 있지만 WIF와 관련이 있는 섹션에만 주석이 적용되어 있습니다.

<?xml version="1.0" encoding="utf-8"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

위의 구성에 대해서는 별도로 설명하지 않습니다.

<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
    <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

위의 구성에서 이 영역은 WIF가 WS-Federation 흐름 및 인증 설정을 모델링하는 데 사용하는 구성 섹션을 읽고 해석하기 위해 ASP.NET에 필요한 클래스를 로드합니다.

  </configSections>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />

위의 구성에 대해서는 별도로 설명하지 않습니다.

    <add key="ida:FederationMetadataLocation" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/federationmetadata/2007-06/federationmetadata.xml" />
    <add key="ida:Issuer" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" />
    <add key="ida:ProviderSelection" value="productionSTS" />
  </appSettings>

위의 구성에서 appSettings 항목은 다른 위치에 저장되지 않는 중요 설정(예: 키 롤오버 섹션에서 사용한 메타데이터 문서의 주소)을 추적하기 위해 ID 및 액세스 도구가 캡처하는 것입니다.

  <location path="FederationMetadata">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="SignOut">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

위의 구성에서 두 개의 <location> 요소는 인증하지 않아도 액세스할 수 있는 웹 응용 프로그램의 두 영역(아래 설명 참조)을 작성합니다. FederationMetadata 섹션은 ID 및 액세스 도구를 통해 작성됩니다. 이 도구에서 응용 프로그램을 설명하는 메타데이터 문서(기관에서 응용 프로그램을 프로비저닝하는 데 사용할 수 있음)를 만듭니다. SignOut 섹션은 웹 로그아웃 구현 방법을 설명하는 지침의 일부분으로 추가한 것입니다.

  <system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="4.5" />
    <!--Commented by Identity and Access VS Package-->
    <!--<authentication mode="Windows" />-->
    <authorization>
      <deny users="?" />
    </authorization>

위의 구성을 사용하는 경우 ID 및 액세스 도구는 기본적으로 위에 나와 있는 예외 항목을 제외한 웹 응용 프로그램의 모든 부분에서 요청을 처리하기 전에 사용자가 인증을 해야 하도록 ASP.NET 인증 및 권한 부여 설정을 지정합니다. 일반적으로 LOB 응용 프로그램의 경우에는 이러한 방식이 적절하지만, 개발자는 익명으로 액세스할 수 있는 영역을 유지하려는 경우도 있습니다. 이러한 경우에는 여기서 설정을 적절하게 변경하면 됩니다.

    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
    <customErrors mode="Off" />
    <machineKey decryptionKey="998D0533DD570FDCA86A945893F0B2BFC0E1F3645E148F35" validationKey="E739C2EA4B4470820308DA71D81160F22C0D9CD3C97709CB0679E55FDCC2D35B35563D56102F254FB4908644ECB53B3898948F54AAC4A5F0C44754A5A997B79A" />
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

위의 구성에 대해서는 별도로 설명하지 않습니다.

    <modules>
      <remove name="FormsAuthentication" />
      <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
    </modules>
  </system.webServer>

위의 구성에서는 이 섹션의 항목이 핵심 프로토콜 및 세션 처리 기능을 구현하는 HTTPModule을 ASP.NET 파이프라인에 삽입합니다. FAM(WSFederationAuthenticationModule)은 프로토콜 사양에 따라 들어오는 토큰의 유효성을 검사하고 기관에 대한 로그온 메시지를 생성하여 WS-Federation을 적용합니다. SAM(SessionAuthenticationModule)은 FAM과 함께 세션 쿠키를 만들고 유효성을 검사합니다.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-1.3.0.0" newVersion="1.3.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="v11.0" />
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>

위의 구성에 대해서는 별도로 설명하지 않습니다.

  <system.identityModel>
    <identityConfiguration>
      <audienceUris>
        <add value="https://localhost:44342/ShiungZZZ" />
      </audienceUris>

위의 구성에서 <system.identityModel>은 모든 WIF 클래스 관련 설정을 래핑합니다. 첫 번째 하위 요소인 IdentityConfiguration은 응용 프로그램 동작에 대한 프로토콜 독립적 설명을 제공합니다. AudienceUris 목록에서는 WIF가 현재 응용 프로그램에 대해 들어오는 토큰에서 적절한 범위로 간주하는 모든 값을 제공합니다. 일반적으로 이러한 값은 응용 프로그램의 영역 또는 앱 ID URI(Azure AD 용어)에 해당합니다. 들어오는 토큰에서는 해당되는 받는 사람이 해당 목록에 포함된 값 중 하나임을 선언해야 합니다. 그렇지 않으면 WIF는 해당 토큰을 도용된 것으로 가정하여 호출을 거부합니다.

           
      <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
        <authority name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/">
          <keys>
            <add thumbprint="3A38FA984E8560F19AADC9F86FE9594BB6AD049B" />
          </keys>
          <validIssuers>
            <add name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/" />
          </validIssuers>
        </authority>
      </issuerNameRegistry>

위의 구성에서 ValidatingIssuerNameRegistry 요소는 적절한 발급자 이름-서명 확인 키 튜플을 포함합니다. 이 연습에서 해당 설정은 Azure AD 테넌트와 연결된 값을 반영합니다. 이 요소를 사용하는 경우에는 다른 회사에서 소유한 기타 Azure AD 테넌트를 비롯한 다른 어떤 발급자도 응용 프로그램에 액세스할 수 없습니다.

<certificateValidation certificateValidationMode="None">
      </certificateValidation>

위의 구성에서 이 요소는 WIF 파이프라인의 인증서 유효성 검사를 해제합니다. 자체 서명 인증서를 사용하는 Azure AD에서는 이러한 방법을 사용해야 합니다. 로컬 인증서 저장소에 인증서 자체를 설치하지 않으면 체인 또는 피어 유효성 검사가 실패합니다. ValidatingIssuerNameRegistry를 통해 올바른 인증서 사용이 보장되므로 Azure AD 인증의 보안이 실제로 저하되지는 않습니다. 그러나 다른 발급자를 신뢰하려는 용도로 동일 응용 프로그램에서 WIF를 사용하는 경우에는 해당 설정이 다른 발급자에게도 확장 적용됩니다.

      <securityTokenHandlers>
        <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      </securityTokenHandlers>
    </identityConfiguration>

이 섹션에서는 WIF가 들어오는 보안 토큰을 처리하는 데 사용하는 클래스 컬렉션(토큰 처리기)을 조작할 수 있습니다. 이를 통해 개별 처리기의 동작을 변경하거나 처리기 유형을 추가 및 제거할 수 있습니다. 여기서는 DPAPI를 기반으로 하며 Azure 웹 사이트에서는 사용할 수 없는 기본 세션 처리기가 제거되고 MachineKey를 사용하는 처리기가 대신 추가되었습니다.

  </system.identityModel>
  <system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="false" />
      <wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" realm="https://localhost:44342/ExpenseReport" requireHttps="false" />
    </federationConfiguration>
  </system.identityModel.services>
</configuration>

위의 구성에서 <system.identityModel.services>는 WS-Federation 관련 정보를 저장하는 데 사용됩니다.

특히 wsFederation 요소는 여기서 Azure AD 테넌트의 WS-Federation 로그온 끝점, 로그온 시 식별자로 전송할 응용 프로그램의 영역(앱 ID URI) 및 WIF의 로컬 동작에 영향을 주는 기타 플래그를 기록하는 데 사용됩니다. 이러한 플래그로는 응용 프로그램에서 401 오류가 발생하는 경우 기관에 대한 로그인 메시지를 항상 트리거할지 여부(passiveRedirectEnabled) 또는 일반 HTTP에 대한 트랜잭션을 허용할지 여부 등이 포함됩니다.

이 요소를 사용하여 기타 여러 프로토콜 매개 변수를 지정할 수도 있습니다. 위의 구성에는 로그온 흐름이 작동하는 데 반드시 필요한 최소한의 매개 변수만 나와 있습니다.

이 문서에서는 .NET 응용 프로그램을 Azure AD에 연결하여 WS-Federation을 통해 웹 로그온을 수행하는 비교적 제한된 작업에 대해 중점적으로 설명했습니다. 그러나 원하는 최신 플랫폼에서 다양한 개방형 프로토콜과 프로그래밍 스택을 활용하거나, 연결된 상태로 프로토콜 수준에서 직접 작업을 수행하여 진행할 수 있는 다른 시나리오도 많이 있습니다.

Azure에 응용 프로그램을 배포하는 방법에 대한 섹션에서도 언급했듯이, 관리 포털에서는 응용 프로그램 등록 설정의 더 많은 요소를 추가로 변경할 수 있습니다. 이 문서 시리즈의 다음 연습에서 이러한 여러 추가 컨트롤에 대해 알아볼 것입니다. 여기서는 웹 로그온 또는 지원되는 기타 흐름을 위해 프로토콜 수준에서 Azure AD와 상호 작용하려는 경우 필요한 정보를 확인할 수 있는 방법만 간략하게 설명하겠습니다.

  1. 브라우저 창에서 Azure 관리 포털을 열고 Azure AD 섹션의 응용 프로그램 헤더로 이동합니다. 화면 아래쪽의 명령 모음에 끝점 보기라는 항목이 있습니다. 해당 항목을 클릭합니다.

    앱 끝점 그러면 표시되는 대화 상자에는 프로그래밍 방식으로 Azure AD 테넌트와 상호 작용하는 데 사용할 수 있는 모든 끝점의 목록이 표시됩니다. 아래에서 모든 항목에 대해 간략하게 설명합니다.

    • 페더레이션 메타데이터 문서: 웹 로그온 기관으로 사용되는 Azure AD 테넌트에 대해 설명하는 메타데이터 문서의 위치입니다. 위의 자동 키 새로 고침 관련 섹션에서 확인한 것처럼 이 문서에는 WS-Federation 메타데이터 정보가 포함되어 있으며, SAML 프로토콜 메타데이터도 동일 패키지에 포함되어 있습니다. 자세한 내용은 Federation Metadata를 참조하십시오.

    • WS-Federation 로그온 끝점: 모든 WS-Federation 트랜잭션용 진입점으로, 연습에서 로그온 및 로그아웃 흐름에 사용했던 끝점입니다. 자세한 내용은 WS-Federation Endpoint URL를 참조하십시오.

    • SAML-P 로그온 끝점: SAML 프로토콜에서 로그온 흐름을 구현하는 데 사용되는 끝점입니다. 자세한 내용은 SAML Protocol Metadata and Endpoints를 참조하십시오.

    • SAML-P 로그아웃 끝점: SAML 프로토콜에서 로그아웃 흐름을 구현하는 데 사용되는 끝점입니다. 자세한 내용은 SAML Protocol Metadata and Endpoints를 참조하십시오.

    • Azure AD Graph 끝점: Graph API 구문을 사용하여 현재 Azure AD 테넌트에 저장된 디렉터리 정보를 검색하기 위한 쿼리의 대상으로 지정해야 하는 끝점입니다. 자세한 내용은 Graph API를 사용하여 Azure AD 쿼리를 참조하십시오.

    • OAuth2 토큰 끝점: 서버 간 인증 흐름에 사용되는 끝점입니다. 예를 들어 Graph 끝점 호출을 위한 액세스 토큰을 가져오려는 경우 이 끝점을 사용할 수 있습니다. 자세한 내용은 OAuth 2.0 (Preview Version)를 참조하십시오.

커뮤니티 추가 항목

표시:
© 2014 Microsoft