이 설명서는 보관되지만 유지 되지 않습니다.

클레임 인식 웹 응용 프로그램 및 서비스의 권한 부여

게시: 2011년 4월

업데이트 날짜: 2015년 6월

적용 대상: Azure

  • Microsoft Azure Active Directory 액세스 제어(액세스 제어 서비스 또는 ACS라고도 함)

  • WIF(Windows® Identity Foundation)

  • ASP.NET

  • WCF(Windows Communication Foundation)

신뢰 당사자 응용 프로그램에서 권한 부여는 인증된 ID가 액세스할 수 있는 리소스와 인증된 ID가 해당 리소스에 대해 수행할 수 있는 작업을 결정합니다. 권한 부여가 부적절하거나 약하면 이는 곧 정보 공개 및 데이터 변조로 이어집니다. 이 항목에서는 ACS 및 WIF를 사용하여 클레임 인식 ASP.NET 웹 응용 프로그램 및 서비스에 대한 권한 부여를 구현하는 데 사용할 수 있는 접근 방식을 간략하게 설명합니다.

  • 클레임을 사용하는 권한 부여 접근 방식을 나열합니다.

  • 각 접근 방식의 개략적인 디자인을 간략하게 설명합니다.

  • 각 접근 방식의 장점과 단점을 설명합니다.

.NET Framework는 첫 번째 버전부터 권한 부여를 구현하는 유연한 메커니즘을 제공해 왔습니다. 이 메커니즘은 두 가지 단순한 인터페이스 IPrincipalIIentity를 기반으로 합니다. IIentity의 구체적 구현은 인증된 사용자를 나타냅니다. 예를 들어 WindowsIdentity 구현은 Active Directory에 의해 인증된 사용자를 나타내고, GenericIdentity는 사용자 지정 인증에 의해 인증된 사용자를 나타냅니다. IPrincipal의 구체적 구현은 역할 저장소에 따라 역할을 사용하여 권한을 확인하는 데 도움이 됩니다. 예를 들어 WindowsPrincipalWindowsIdentity에 Active Directory 그룹의 멤버 자격이 있는지 확인합니다. 이 확인은 IPrincipal 인터페이스에서 IsInRole 메서드를 호출하여 수행됩니다. 역할을 기반으로 액세스 권한을 확인하는 것을 RBAC(역할 기반 액세스 제어)라고 합니다. RBAC는 이 항목의 “역할 기반 액세스 제어” 섹션에 설명되어 있습니다. 클레임을 사용하여 역할에 대한 정보를 전달함으로써 익숙한 역할 기반 권한 부여 메커니즘을 지원할 수 있습니다.

또한 클레임을 사용하면 역할 이상의 훨씬 더 풍부한 권한 부여 결정이 가능합니다. 클레임은 사실상 모든 것(연령, 우편 번호, 신발 크기 등)을 기반으로 할 수 있습니다. 임의 클레임을 기반으로 액세스 권한을 확인하는 것을 CBAC(클레임 기반 액세스 제어) 또는 클레임 기반 권한 부여라고 합니다. 클레임 기반 권한 부여는 이 항목의 “클레임 기반 액세스 제어” 섹션에 설명되어 있습니다.

권한 부여 확인은 ACS 쪽에서가 아니라 응용 프로그램 쪽에서 수행됩니다. ACS는 클레임을 응용 프로그램에 전달하는 토큰을 발급하는 STS(보안 토큰 서비스) 역할을 합니다. 토큰은 ID 공급자에 의해 클레임으로 보강되며, 선택적으로 ACS가 자체적으로 해당 규칙 엔진을 사용하여 토큰을 클레임으로 보강하기도 합니다. 응용 프로그램은 클레임이 포함된 토큰을 받으면 토큰을 구문 분석하고 관련 클레임을 추출하며 RBAC 또는 클레임 기반 접근 방식을 사용하여 권한 부여를 결정할 수 있습니다. WIF를 사용하여 토큰을 구문 분석하고 구문 분석한 내용을 사용하기 쉬운 API(응용 프로그래밍 인터페이스)를 통해 권한 부여 결정에 유용하게 사용할 수 있습니다. WIF에 대한 자세한 내용은 WIF SDK(http://go.microsoft.com/fwlink/?LinkID=187481)를 참조하세요. 클레임 인식 응용 프로그램 및 서비스의 권한 부여에 대해 생각할 때 다음 다이어그램을 고려하세요. 인증에 성공하면 ID 공급자는 토큰(다이어그램의 IdP 토큰)을 생성합니다. IdP 토큰은 ACS 규칙 엔진에 의해 변환될 수 있습니다. ACS는 ID 공급자가 발급한 토큰에 포함된 클레임을 추가, 제거 또는 변경할 수 있습니다. 마지막으로, ACS에서 발급한 토큰은 응용 프로그램으로 전송되고 WIF에 의해 처리됩니다. 액세스 권한 확인은 RBAC 또는 CBAC 접근 방식을 통해 WIF에서 수행됩니다.

ACS v2 WIF 권한 부여

RBAC는 사용자 권한이 사용자 역할을 기반으로 응용 프로그램에 의해 관리 및 적용되는 권한 부여 접근 방식입니다. 사용자에게 작업을 수행하는 데 필요한 역할이 있는 경우 액세스 권한이 부여되고, 그렇지 않으면 액세스 권한이 거부됩니다.

클레임 인식 응용 프로그램에서 RBAC 접근 방식을 구현하려면 비 클레임 인식 응용 프로그램에서 하는 것처럼 IPrinicpal 인터페이스 IsInRole() 메서드를 사용하면 됩니다. IsInRole() 메서드를 사용하는 방법은 다음과 같이 여러 가지입니다.

  • IPrincipal.IsInRole(“Administrator”)에 대해 명시적으로 호출. 이 접근 방식에서 결과는 부울입니다. 조건부 문에 이 접근 방식을 사용합니다. 코드 내의 아무 곳에나 임의로 이 접근 방식을 사용할 수 있습니다.

  • 보안 요청 PrincipalPermission.Demand() 사용. 이 접근 방식에서 결과는 요청이 충족되지 않는 경우 예외입니다. 이 접근 방식은 예외 처리 전략에 맞아야 합니다. 예외를 throw하는 것은 성능 관점에서 봤을 때 부울을 사용 중지하는 것에 비해 훨씬 더 비용이 많이 듭니다. 코드 내의 아무 곳에나 이 접근 방식을 사용할 수 있습니다.

  • 선언적 특성 [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)] 사용. 이 접근 방식은 메서드를 데코레이팅하는 데 사용되므로 선언적이라고 합니다. 이 접근 방식은 메서드 구현 내의 코드 블록에는 사용할 수 없습니다. 결과는 요청이 충족되지 않는 경우 예외입니다. 이 접근 방식이 예외 처리 전략에 맞는지 확인해야 합니다.

  • URL 권한 부여 사용(web.config<authorization> 섹션 사용). 이 접근 방식은 URL 수준에서 권한 부여를 관리하는 경우 적합합니다. 이 접근 방식은 앞에서 언급한 접근 방식 중에서 가장 대략적인 수준입니다. 이 접근 방식의 장점은 변경이 구성 파일에서 이루어진다는 점입니다. 즉, 변경 내용을 활용하기 위해 코드를 컴파일할 필요가 없습니다.

IsInRole() 메서드가 호출되면 현재 사용자에게 해당 역할이 있는지 확인하기 위한 검사가 수행됩니다. 클레임 인식 응용 프로그램에서 역할은 토큰에서 사용할 수 있어야 하는 역할 클레임 유형으로 표현됩니다. 역할 클레임 유형은 다음 URI를 사용하여 표현됩니다.

http://schemas.microsoft.com/ws/2008/06/identity/claims/role

토큰을 역할 클레임 유형으로 보강하는 방법은 다음과 같이 여러 가지입니다.

  • ACS 규칙 엔진 사용 - 이 경우 ACS 관리 포털 또는 ACS 관리 서비스를 통해 규칙을 만들어 특정 역할 유형의 클레임을 생성하는 클레임 변환 규칙을 만듭니다. 규칙 및 토큰 변환에 대한 자세한 내용은 규칙 그룹 및 규칙방법: 규칙을 사용하여 토큰 변환 논리 구현을 참조하세요.

  • ClaimsAuthenticationManager를 사용하여 임의 클레임을 클레임 역할 유형으로 변환 - ClaimsAuthenticationManager는 WIF의 일부로 제공되는 구성 요소로서, 요청이 응용 프로그램을 시작할 때 요청을 가로챌 수 있도록 하여 토큰을 검사하고 클레임을 추가, 변경 또는 제거하여 토큰을 변환할 수 있게 해줍니다. ClaimsAuthenticationManager를 사용하여 클레임을 변환하는 방법에 대한 자세한 내용은 방법: WIF 및 ACS를 사용하여 클레임 인식 ASP.NET 응용 프로그램에서 RBAC(역할 기반 액세스 제어) 구현을 참조하세요.

  • samlSecurityTokenRequirement 구성 섹션을 사용하여 임의 클레임을 역할 유형에 매핑 - 클레임을 변환하는 데 구성만 사용하고 코딩은 필요하지 않은 선언적 접근 방식입니다.

CBAC는 액세스 권한을 부여하거나 거부하는 권한 부여 결정이 결정을 위해 클레임에서 사용 가능한 데이터를 사용하는 임의 논리를 기반으로 하는 권한 부여 접근 방식입니다. RBAC의 경우를 상기해 보세요. 사용되는 유일한 클레임은 역할 유형 클레임이었습니다. 역할 유형 클레임은 사용자가 특정 역할에 속하는지 여부를 확인하는 데 사용되었습니다. 클레임 기반 권한 부여 접근 방식을 사용한 권한 부여 결정 프로세스를 보여 주기 위해 다음 단계를 고려하세요.

  1. 응용 프로그램이 요청을 받습니다.

  2. 응용 프로그램이 들어오는 클레임을 추출합니다.

  3. 응용 프로그램이 클레임을 결정 논리 메커니즘에 전달합니다. 결정 논리 메커니즘은 메모리 내 코드이거나 웹 서비스에 대한 호출, 데이터베이스에 대한 쿼리이거나 정교한 규칙 엔진을 호출할 수 있습니다.

  4. 결정 메커니즘에서는 클레임을 기반으로 결과를 계산합니다.

  5. 결과가 true인 경우 액세스 권한이 부여되고, false인 경우 거부됩니다. 예를 들어 규칙은 사용자의 연령이 21세 이상이고, 워싱턴주에 살며, Windows Live ID(Microsoft 계정)로 인증된 사용자일 수 있습니다.

ACS는 클레임을 전달하는 토큰을 발급하는 STS 역할을 합니다. ACS 규칙 엔진을 사용하여 발급되는 클레임을 제어할 수 있습니다(클레임 유형 및 값 유형). ACS 규칙 엔진에 대한 자세한 내용은 규칙 그룹 및 규칙방법: 규칙을 사용하여 토큰 변환 논리 구현을 참조하세요. ClaimsAuthorizationManager는 클레임 인식 응용 프로그램에서 CBAC를 구현하는 데 핵심적인 역할을 담당합니다. ClaimsAuthorizationManager는 WIF의 일부로 제공되는 구성 요소입니다. ClaimsAuthorizationManager를 사용하여 들어오는 요청을 가로채고 원하는 논리를 구현하여 들어오는 클레임을 기반으로 권한 부여를 결정할 수 있습니다. 또한 ClaimsAuthorizationManager는 권한 부여 결정이 응용 프로그램 코드에서 표면화 및 분리될 수 있는 확장성 요소입니다. 이는 권한 부여 논리를 변경해야 할 경우 중요합니다. 이 경우 ClaimsAuthorizationManager를 사용하는 것이 응용 프로그램의 무결성에 영향을 주지 않아 변경 결과로 응용 프로그램 오류가 발생할 가능성이 줄어듭니다. ClaimsAuthorizationManager를 사용하여 클레임 기반 액세스 제어를 구현하는 방법에 대한 자세한 내용은 방법: WIF 및 ACS를 사용하여 클레임 인식 ASP.NET 응용 프로그램에서 클레임 권한 부여 구현을 참조하세요.

참고 항목

표시: