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

액세스 제어 서비스를 사용한 서비스 버스 인증 및 권한 부여

Windows Azure Service Bus는 Windows Azure Active Directory 액세스 제어(액세스 제어 서비스 또는 ACS라고도 함)를 사용하여 Service Bus 작업에 권한을 부여할 수 있습니다.

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

ACS는 호출자 ID를 설정하여 인증을 쉽게 수행할 수 있도록 합니다. ACS에서는 두 가지 방법을 통해 호출자 ID를 설정합니다. 그중 한 가지 방법은 기존의 사용자 이름 및 암호 체계를 사용하는 서비스 ID 또는 계정의 네임스페이스 범위 목록을 기반으로 하여 ID를 설정하는 것이고, 다른 하나는 ADFS(Active Directory Federation Services), Windows Live ID, Facebook, Google ID, Yahoo ID, OpenID 등의 외부 ID 공급자에게 ID 설정 작업을 위임하는 것입니다.

ID가 설정되고 나면 ACS는 해당 ID에 대한 여러 '클레임'을 포함하거나 받습니다. 이러한 클레임은 사용자 또는 사용자가 아닌 계정을 설명하며, 클레임을 발급한 ID 공급자에 의해 디지털로 서명됩니다. 따라서 클레임이 올바르거나 적어도 발급자의 관리 계획 규칙을 따른다는 것을 ACS에서 확인할 수 있습니다. 즉, 제공된 ID가 "Microsoft Corporation 회장 Bill Gates"임을 나타내는 클레임 집합은 Microsoft ADFS 게이트웨이에서 발급된 경우 신뢰도가 높지만 타사에서 발급된 경우에는 신뢰도가 떨어집니다. 모든 ID 공급자와 ACS 기본 제공 서비스 ID에 대해 일관되게 사용 가능한 클레임은 공급자 자체를 식별하는 공급자 클레임이자 지정된 ID에 대한 공급자 관련/공급자 고유 식별자인 'nameidentifier' 클레임입니다.

둘째로, ACS는 ID 공급자가 발급한 클레임을 '신뢰 당사자'가 이해할 수 있는 클레임으로 매핑하도록 허용함으로써 권한을 원활하게 부여할 수 있도록 합니다. Service Bus가 해당 신뢰 당사자이며 ACS를 사용하여 인증 및 권한 부여를 처리함을 의미합니다. 클레임 서버 매핑은 두 가지 용도로 사용됩니다. 그중 첫 번째 용도는 서로 다른 여러 클레임 용어로 된 클레임을 서비스에서 이해할 수 있는 단일 클레임 집합으로 일반화하는 것이고, 두 번째 용도는 권한 부여 규칙 집합 역할을 하는 것입니다. 지정된 ID가 서비스에서 이해할 수 있는 클레임 집합에 매핑되어 있지 않은 경우 해당 ID는 서비스에 액세스할 수 없습니다.

인증 및 권한 부여는 항상 클라이언트를 통과하며, 모든 당사자를 네트워크에서 직접 표시하도록 요구하는 구성 요소는 클라이언트뿐입니다. 예를 들어 회사 방화벽 외부에서는 표시되지 않는 AD FS 서비스를 ACS와 함께 사용할 수 있습니다. ACS와 AD FS는 서로 직접 통신하지 않기 때문입니다. 클라이언트는 보호된 리소스에 대해 Service Bus 큐로 메시지 보내기 등의 작업을 수행해야 할 때마다 해당 작업을 수행할 권한을 부여받았다는 증명을 얻어야 합니다. 이 증명은 '토큰' 형태로 ACS에서 얻습니다. 토큰은 단순한 클레임 집합의 컨테이너이며 발급자가 디지털 서명을 합니다. ACS가 AD FS 등의 외부 ID 공급자를 사용하여 ID를 설정하도록 구성되어 있으면 최소한 두 개의 토큰이 사용됩니다. AD FS 등의 ID 공급자에서 얻을 수 있는 첫 번째 토큰은 사용자 ID에 대한 여러 가지 증명 종류 중 하나를 입력으로 제공합니다. 그런 후 이 토큰은 ACS로 전달되며, 액세스 제어는 이 토큰을 평가하고 규칙을 실행한 다음 신뢰 당사자용으로 토큰을 내보냅니다.

Service Bus 및 ACS

Service Bus 및 ACS에는 특수한 관계가 있습니다. 즉, 각 Service Bus 서비스 네임스페이스("-sb" 접미사가 붙음)는 같은 이름의 일치하는 ACS 서비스 네임스페이스와 쌍을 이룹니다. Service Bus 및 ACS에서 상호 트러스트 관계와 연결된 암호화 암호를 관리하는 방식으로 인해 이러한 특수 관계가 사용됩니다.

Service Bus는 ACS V1 및 ACS V2와 모두 페더레이션할 수 있습니다. 2011년 9월 Service Bus 릴리스 이전에 만들어진 모든 서비스 네임스페이스는 ACS V1과 페더레이션되고 서비스 업그레이드 이후에 만들어진 모든 서비스 네임스페이스는 ACS V2와 페더레이션됩니다. 이 항목에서는 ACS 서비스의 최신 릴리스인 ACS V2에 대해서만 다룹니다.

"-sb" ACS 서비스 네임스페이스(Windows Azure 포털에서 Service Bus 서비스 네임스페이스를 선택한 다음 리본 메뉴에서 ACS 아이콘을 클릭하면 확인할 수 있음)는 '신뢰 당사자 응용 프로그램' 탐색을 따르는 "ServiceBus" 신뢰 당사자 정의입니다. 신뢰 당사자 정의는 일치하는 Service Bus 서비스 네임스페이스('http' 스키마 사용) 루트에 대한 'Realm' 값 매핑을 포함하며 토큰 유형은 'SWT'로, 토큰 만료 시간은 1200초로 설정합니다. 또한 서명 키는 포털 또는 API를 통해 관리하거나 액세스할 수 없습니다.

"ServiceBus" 신뢰 당사자 정의에는 "Service Bus에 대한 기본 규칙 그룹"이 연결되어 있습니다. 이 그룹은 서비스 네임스페이스의 '소유자'가 서비스 네임스페이스의 슈퍼 사용자로서의 역할을 할 수 있는 기본 매핑을 포함합니다. 규칙 그룹에는 기본적으로 "소유자" 서비스 ID에 대한 입력 'nameidentifier' 클레임을 Service Bus에서 이해할 수 있는 세 가지 권한 클레임(모든 보내기 작업의 경우 'Send', 수신기를 열거나 메시지를 받으려는 경우 'Listen', Service Bus 테넌트 상태를 관찰하거나 관리하려는 경우 'Manage')에 매핑하는 세 개의 간단한 규칙이 포함되어 있습니다. Service Bus는 제출된 토큰에 포함된 다른 모든 클레임을 무시합니다. "소유자" 서비스 ID는 ACS 서비스 네임스페이스의 일반 서비스 ID입니다. ID는 더 만들 수 있으며 더 만드는 것이 좋습니다. 실제로 "소유자" ID는 관리 작업 수행 시에만 사용해야 합니다.

신뢰 당사자 정의 및 범위

클라이언트가 https://tenant.servicebus.windows.net/my/test와 같은 위치에 있는 큐로 메시지를 보내기 위한 권한 부여 토큰을 요청하는 경우 해당 토큰 요청에는 대상 주소의 일반화된 형식이 올바른 대상 영역으로 포함됩니다. 이 '일반화'에서는 모든 프로토콜에 대해 단순히 공통 URI 스키마를 사용합니다. 따라서 https://tenant.servicebus.windows.net/my/test 또는 sb://tenant.servicebus.windows.net/my/test에 있는 Service Bus 엔터티와 상호 작용하기 위한 토큰 요청 작업은 항상 'http' 스키마 http://tenant.servicebus.windows.net/foo/bar를 사용하는 영역 URI를 통해 수행됩니다. 따라서 모든 신뢰 당사자 정의에서도 영역 URI에 대해 '일반화된' URI 스키마 'http'를 사용해야 합니다.

요청이 ACS에 도착하면 ACS에서는 '가장 긴 접두사 일치' 방식을 통해 영역 URI를 신뢰 당사자 정의에 일치시킵니다. 이 방식에서는 '영역 URI' 주소가 토큰 요청 대상 주소에 대해 사용 가능한 가장 긴 접두사인 신뢰 당사자, 신뢰 당사자 정의 및 연결된 규칙 정의가 선택 및 실행됩니다. 기본 'ServiceBus' 신뢰 당사자 정의의 범위는 해당하는 Service Bus 서비스 네임스페이스 전체로 지정됩니다. 즉, Service Bus 서비스 네임스페이스 루트 주소에 해당하는 영역 URI는 Service Bus 서비스 네임스페이스에 포함될 수 있는 모든 주소에 대한 접두사입니다. 그러므로 해당 신뢰 당사자 정의에서 사용하도록 설정된 규칙 정의는 전체 Service Bus 서비스 네임스페이스에 대한 모든 권한을 부여합니다.

https://tenant.servicebus.windows.net/my/test와 같은 위치에 있는 큐에 대해 범위가 지정된 권한 부여 규칙 집합을 만들 때는 새 신뢰 당사자 정의를 만들어 큐의 주소 또는 해당 주소의 접두사를 새 정의의 영역 URI로 제공합니다 이 작업은 ACS 포털 또는 ACS 관리 API를 통해 수행합니다. 포털을 사용하는 경우 다음과 같은 단계를 수행합니다.

  • 신뢰 당사자 응용 프로그램에서 추가를 클릭합니다.

  • MyTest와 같은 표시 이름을 입력합니다.

  • 범위의 영역 URI로 http://tenant.servicebus.windows.net/MyTest를 입력합니다.

  • 토큰 형식으로 SWT를 선택합니다.

  • 암호화 정책을 없음으로 설정합니다.

  • 토큰 수명을 1200초로 설정합니다.

  • 저장을 클릭합니다.

그러면 해당 주소에 단독으로 사용되는 신뢰 당사자 정의가 작성됩니다. 이 정의의 영역 URI는 기본 제공 'ServiceBus' 신뢰 당사자 정의의 접미사이므로, 이 정의는 Service Bus가 새 정의를 기반으로 발급된 토큰을 신뢰하도록 올바른 서명 키를 자동으로 상속합니다. 그러나 새 신뢰 당사자 정의에는 규칙이 연결되어 있지 않으므로 이 시점까지는 "소유자"를 비롯한 누구도 큐에 액세스할 수 없습니다. 신뢰 당사자 정의가 계층 구조를 형성한다 하더라도 정의 간에 규칙이 암시적으로 자동 상속되지는 않기 때문입니다.

새 정의를 만들고 나면 ACS 포털의 규칙 그룹 섹션에는 "<표시 이름>에 대한 기본 규칙 그룹"이 생성됩니다. 이 새 그룹은 기본적으로 비어 있습니다. 큐에 대한 액세스를 허용하려면 그룹에 규칙을 허용해야 합니다. 이 작업에 대해서는 다음 섹션에서 설명합니다. 이미 규칙이 포함되어 있는 기존 규칙 그룹을 신뢰 당사자 정의에 대해 사용하도록 설정할 수도 있습니다. 각 규칙 그룹은 신뢰 당사자 계층 구조의 어느 위치에서나 사용하도록 설정할 수 있는 개별 액세스 제어 목록으로 볼 수 있습니다. Service Bus 서비스 네임스페이스 루트의 기본 규칙을 상속하는 것과 같은 파일 시스템 방식 상속을 사용하려면 해당 "ServiceBus에 대한 기본 규칙 그룹" 및 기타 규칙 그룹을 신뢰 당사자 정의에 대해 사용하도록 설정하면 됩니다. 이렇게 하려면 포털에서 신뢰 당사자 정의의 '규칙 그룹' 섹션에 있는 오른쪽 확인란을 선택해야 합니다. http://tenant.servicebus.windows.net/my/test 및 http://tenant.servicebus.windows.net/my/zoo에 있는 형제 큐와 같은 병렬 리소스 집합에 대해 공통 규칙을 적용하는 경우와 같이 여러 리소스에 공통 액세스 규칙 집합을 적용해야 하는 경우에는 신뢰 당사자 정의의 범위를 http://tenant.servicebus.windows.net/my와 같은 공유 서비스 네임스페이스 분기로 지정할 수도 있습니다.

항목의 각 구독에 대한 사용 권한이 서로 다른 등, 같은 Service Bus 엔터티의 각 측면에 대해 액세스 제어를 서로 다른 방식으로 관리해야 하는 시나리오도 있습니다. 이러한 경우에는 http://tenant.servicebus.windows.net/my/test/subscriptions/sub1/과 같이 특정 구독 이름으로 범위가 지정된 신뢰 당사자 정의를 만든 다음 특정 명명된 구독에만 적용되는 규칙을 해당 정의에 포함할 수 있습니다.

규칙 정의

규칙은 규칙 그룹에서 정의되며 보통 입력 클레임을 출력 클레임에 매핑합니다. 그룹의 모든 규칙은 하나로 결합된 결과를 생성하므로, 지정된 입력 클레임 집합에 대해 각각 다른 출력 클레임 3개를 생성하는 일치 규칙 3개가 있는 경우 발급되는 권한 부여 토큰에는 3개 클레임이 모두 포함됩니다. Service Bus의 경우 이 세 권한 클레임은 모든 보내기 작업의 경우 'Send', 수신기를 열거나 메시지를 받으려는 경우 'Listen', Service Bus 테넌트 상태를 관찰하거나 관리하려는 경우 'Manage'입니다. 좀 더 정확하게 설명하자면 'Send', 'Listen', 'Manage'는 클레임 유형 'net.windows.servicebus.action'에 대해 허용되는 값입니다. Service Bus에 대해 규칙을 만들려면 서비스 ID의 nameidentifier와 같은 입력 클레임을 원하는 권한 클레임에 매핑해야 합니다. 예를 들어 큐에 대한 'Send' 권한을 서비스 ID "contoso"에 부여하려는 경우 규칙 정의는 값이 "contoso"인 발급자의 nameidentifier 클레임을 값이 'Send'인 'net.windows.servicebus.action' 유형의 사용자 지정 출력 클레임에 매핑합니다. 서비스 ID에 세 가지 권한 클레임을 모두 부여하려면 규칙 3개가 필요합니다. 권한 클레임이 3개뿐인 이유는 규칙 정의의 복잡도를 제한하기 위해서입니다.

토큰 공급자 사용

토큰 공급자는 특정 형식의 자격 증명을 ACS 서비스에 의해 발급된 권한 부여 토큰으로 변환할 수 있도록 하는 Service Bus용 .NET 관리되는 API의 일반 구문입니다. 이렇게 변환된 토큰을 Service Bus에 전달하여 원하는 작업을 수행할 수 있습니다. TokenProvider는 대부분의 기본 시나리오에서 팩터리 메서드를 통해 액세스할 수 있는 3가지 개별 구현이 포함된 추상 기본 클래스입니다.

  • 공유 암호 - ACS의 Service Bus 서비스 네임스페이스 "sb" 버디 네임스페이스에 정의된 서비스 ID 및 해당 ID와 연결된 공유 키를 기반으로 토큰을 가져올 수 있도록 합니다. 서비스 네임스페이스 생성 시 만들어진 미리 프로비전된 서비스 ID를 "소유자"라고 하며, 소유자의 공유 암호는 관리 포털을 통해 사용할 수 있습니다.

  • SWT(Simple Web Token) – 토큰 공급자를 통해 이전에 얻어 ACS로 전달한 SWT 토큰을 기반으로 토큰을 가져올 수 있도록 합니다. 이 토큰은 WS-Trust/WS-Federation RST/RSTR 요청을 사용하여 이진 토큰으로 ACS에 전달됩니다. WS-Federation 공급자를 구성하는 방법에 대한 자세한 내용은 ACS 설명서를 참조하십시오.

  • SAML – 토큰 공급자를 통해 이전에 얻어 ACS로 전달한 SAML 토큰을 기반으로 토큰을 가져올 수 있도록 합니다. 이 토큰은 WS-Trust/WS-Federation RST/RSTR 요청을 사용하여 ACS에 전달됩니다. WS-Federation 공급자를 구성하는 방법에 대한 자세한 내용은 ACS 설명서를 참조하십시오.

Service Bus MessagingFactory, NamespaceManagerTransportClientEndpointBehavior API는 TokenProvider 인스턴스를 허용합니다. 토큰이 필요하면 토큰 공급자가 호출되는데, 여기에는 기존 토큰의 만료 기간(기본값: 1200초)이 경과한 후 수명이 긴 연결에서 새 토큰을 얻어야 하는 시나리오가 포함됩니다. 사용자 상호 작용이 필요한 페더레이션 시나리오에서는 사용자 지정 토큰 공급자를 구현해야 합니다.

예를 들어 특정 Facebook 사용자가 특정 큐로 메시지를 보낼 수 있도록 하는 사용자 지정 토큰 공급자는 ACS를 통해 Facebook ID 설정을 위한 적절한 Facebook UI를 사용자에게 제공하고, ACS를 통해 리디렉션하여 Service Bus용 Facebook 토큰을 ACS 토큰과 교환한 다음 요청이 로컬 응용 프로그램으로 리디렉션되면 ACS 토큰을 추출합니다. 사용자 지정을 위한 토큰 공급자 예제 모음은 Service Bus Codeplex 사이트에서 제공되며 새로운 예제가 계속 추가되고 있습니다.

커뮤니티 추가 항목

표시:
© 2014 Microsoft