Windows Workflow
4 WF 워크플로 서비스의 보안을 위해
Zulfiqar Ahmed
Windows Workflow Foundation (WF)은 소프트웨어 논리를 눈에 보이는 형태로 만들 수 있도록 합니다. 소프트웨어는 논리를 워크플로로 구현 된 후 해당 워크플로 호스트에서 워크플로를 호스트 하 여 수행 합니다. 워크플로 서비스에서 워크플로를 사용 하 여 구현 되는 특수 한 유형의 웹 서비스에서이 워크플로 WorkflowServiceHost 서비스를 호스트 하 여 소비자가 사용할 수 있게 됩니다. 이 기사에서는 다양 한 워크플로 호스트 보안 옵션에 대 한 자세한 내용은 워크플로 서비스와 WorkflowServiceHost에 특히 중점을 두고 설명 합니다. 워크플로 서비스의 보안 경계를 워크플로 계층으로 확장 하는 데 사용할 수 있는 몇 가지 주요 확장 지점에 대해 설명 합니다. 또한 Security Workflow Pack (WFSP) 프로젝트를 소개 하 고 있으며 해당 활동의 컬렉션을 사용 하 여 워크플로 솔루션에 종단 간 보안을 유지 하는 방법에 대해 설명 합니다. Microsoft . NET Framework에 포함 된 4 WF 4는 확장 가능한 호스팅 API와 다양 한 기능을 갖춘 기본 제공 되는 세 가지 워크플로 호스트를 제공 합니다.
WorkflowInvoker 가장 기본적이 고 기능이 가장 적은 호스트 인터페이스에서 워크플로를 호출 하기 위한 간단한 API를 제공 합니다. WorkflowInvoker 개체는 정적 생성자와 Invoke 메서드를 통해 전달 되는 워크플로 인스턴스를 하나만 지원 합니다. 모든 워크플로는 호출 스레드에서 실행 된다는 것을 보증 하기 때문에 호출 하는 코드의 보안 컨텍스트를 가장 한 면이 가장 된 컨텍스트에서 실행 될 수 있습니다. WorkflowInvoker는 진정한 의미의 워크플로 호스트 하지 않습니다. 어느 쪽이 든, WorkflowApplication 기반 호스트를 캡슐화 하 여 펌프를 기준으로 동기화 컨텍스트를 사용 하 여 사용이 편리한 API 및 일관 된 실행 의미 체계를 제공 하는 호스트입니다. 예를 들어 예외 또는 트랜잭션과 같은 호출 경계 간의 원활한 교류. 이 동작은 보안을 쉽게 만드는 워크플로 실행 전체에서 호출자의 보안 컨텍스트를 사용할 수 있으므로이 작업은 보안을 위한 다양 한 시나리오에서이 컨텍스트를 사용할 수 있습니다. 예를 들어, 권한 부여 및 PrincipalPermission Kerberos 위임은 WorkflowInvoker와 완벽 하 게 작동 합니다.
WorkflowApplication 약간의 기능이 추가 되어 있지만 여전히 한 개의 인스턴스를 지원 하지 않습니다. 이 호스트는 CLR ThreadPool의 IO 스레드를 사용 하 여 워크플로를 실행 합니다. 호출 스레드의 보안 컨텍스트는 워크플로 스레드에 복사 되지 않기 때문에 워크플로 클라이언트를 가장 한도에서 작업을 실행 하는 스레드는 가장 된 WF 되지 않습니다. 호출자의 보안 컨텍스트는 다음과 같이 사용자 지정 동기화 컨텍스트를 사용 하 여 WF 스레드에 전달 될 수 있습니다. 이 사용자 지정 동기화 컨텍스트는 원래 WorkflowInvoker에서 사용 되는 동기화 컨텍스트 뿐만 아니라 동일한 스레드에서 비동기 들어오는 호출을 전달 합니다.
public class MySyncContext : SynchronizationContext
{
public override void Post(SendOrPostCallback d, object state)
{
d(state);
}
}
WorkflowServiceHost: 가장 포괄적인 호스트에서 워크플로의 여러 인스턴스가에 적합 한 호스팅 환경을 제공 합니다. 워크플로 서비스를 구현 하는 워크플로를 기반으로 하는 특수 한 유형의 웹 서비스입니다. WorkflowServiceHost는 표준 Windows Communication Foundation (WCF) ServiceHostBase 클래스에서 파생 되므로 모든 WCF 보안 개념이 WorkflowServiceHost에도 적용 됩니다. 메시징 작업은 WorkflowHostingEndpoint와 함께 WorkflowServiceHost에서 지원 되는 주요 상호 작용 모델입니다. WorkflowHostingEndpoint는 메시징 작업을 사용 하지 않고도 WorkflowServiceHost를 사용 가능 하 게 합니다. 이 기사에서는 주로 메시징 작업 워크플로 서비스의 보안 및 WorkflowServiceHost 측면에 중점을 두고 설명 합니다. 워크플로 서비스 기술에 대해, Leon Welicki 씨가 집필 한 2010 년 3 월호 MSDN 매거진 기사 「 4 WCF와 WF에서 워크플로를 시각적 디자인 」 (msdn.microsoft.com/magazine/ff646977) 를 참조 하십시오..
워크플로 서비스의 네트워크 보안
워크플로 서비스는 표준 WCF 서비스 이기 때문에, 네트워크 보안의 측면은 WCF 표준 바인딩 메커니즘을 사용 하 여 구성 합니다. 워크플로 서비스에서 서비스의 보안 요구 사항 마다 특정 바인딩을 사용 하는 하나 이상의 끝점을 사용 하 여 게시할 수 있습니다. WCF 전송 파이프라인은 들어오는 메시지가 대상 끝점의 보안 요구 사항을 충족 하는 경우에만 수행 됩니다. 워크플로 논리는 디스패치 파이프라인의 끝에서 실행 되기 때문에, 일반적인 WCF 확장 지점은 워크플로 서비스에도 적용 가능 합니다. 예를 들어 표준 ServiceAuthorizationManager 확장 지점은 워크플로 서비스에 권한을 적용 하는 데 사용할 수 있습니다. Windows Foundation Identity (WIF)와 같은 프레임 워크를 발송자 수준에서 WCF에 통합 하 고 사용자가 인식 하는 것 없이는이를 워크플로 서비스와 함께 사용할 수 있습니다. WCF와 WF 계층 사이에 존재 하는 여러 비동기 점에 대하여 스레딩에 약간의 차이가 있습니다. 따라서 워크플로 서비스에 특정 스레드 로컬 저장소 (TLS)와 관련 된 시나리오를 조금 어렵습니다. 예를 들어 WIF은 들어오는 Thread.CurrentPrincipal을 ID 정보를 사용 하 여 공개 하 고이 ID는 사용자 코드 기반 서비스에 적합 하 게 설정할 수 있도록 합니다. 그러나 워크플로 논리는 원시 WCF의 스레드가 아닌 다른 스레드에서 실행 되도록 할 수 있습니다. 이 경우 Thread.CurrentPrincipal TLS를 포함 한 모든 관련 데이터가 사용 되지 않으므로 워크플로는 TLS에 의존 하지 않는 것이 좋습니다. 이 문제에 대 한 몇 가지 해결 방법에 대해서는 기사의 뒷부분에서 설명 합니다.
또한 WF는 워크플로 내의 4에서 다른 웹 서비스를 호출 하는 보내기 작업을 제공 합니다. 보내기 작업은 워크플로 내에서 다른 서비스를 호출할 때 사용 되는 바인딩을 사용 하 여 구성할 수 있습니다. 내부적으로는 Send 작업은 WCF ChannelFactory/Channel API를 사용 하 여 메시지를 보낼 수 있도록 구성한 바인딩이이 내부 채널 팩터리를 만드는 데 사용 됩니다. Send 작업에는 ChannelFactory/Channel 캐싱에 사용 되는 내장 캐시 계층입니다. 기본적으로 보내기 작업의 속성을 사용 하 여 끝점 정보를 직접 지정 하 여 구성 된 바인딩 요소가 선택 된 경우에만 캐시 계층에서 사용 됩니다 (그림 1 참고).
.png)
그림 1보내기 작업 속성
EndpointConfigurationName 속성을 사용 하 여 구성 파일에서 끝점 정보를 로드 하는 즉시 보안 캐시가 무효화 되 고 Send 활동이 실행 될 때마다 새로운 채널 팩터리를 만듭니다. WsHttpBinding 또는 wsFederationHttpBinding 등 보안 바인딩에서는 채널 팩터리 열기에 작업이 상당히 많이 수행 되므로 각 메시지에 대 한 채널 팩터리를 다시 만든 후에 비용이 많이 소요 될 수 있습니다. 예를 들어 기본 WSHttpBinding은 성능과 보안 향상을 위해 최적화 됩니다. 이 최적화는 보안 대화 세션을 처음 비용을 들 여 세운 뒤에 오는 메시지를 훨씬 적은 비용으로 보안을 설정 하 여 수행 됩니다. 모든 비즈니스 메시지는 4 개의 추가 인프라 메시지를 전송 하 여 서비스 자격 증명을 협상 하는 보안 대화 세션을 설정 하는 채널 팩터리 캐시 하지 않고, WSHttpBinding의이 동작이 압축 오버 헤드 (그림 2 참고).
그림 2서비스 자격 증명을 협상 하기 위해 보낸 메시지 인프라
| https://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue |
| https://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Issue |
| https://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT |
| http://tempuri.org/IPingService/Ping |
| https://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel |
WF 4에서는 구성 파일에서 로드 된 모든 바인딩 구성 (기본 바인딩 포함), Send 동작에 의해 "안전 하 게 캐시 되지 않은"간주 되는 채널 팩터리 캐시를 사용할 수 없습니다. 이 기본 동작은 보안 되지 않은 채널 캐시를 강제로 사용 하 여 재정의할 수 있습니다. 따라서 동일한 끝점으로 메시지를 보내는 채널 팩터리가 재사용 될 수 있습니다. SendMessageChannelCache 서비스 동작은 안전 하지 않은 캐시를 활성화 하 고 다양 한 채널 및 채널 팩터리 캐시 설정을 구성할 수 있습니다 (아래 그림 참조).
<serviceBehaviors>
<behavior>
<sendMessageChannelCache allowUnsafeCaching="true">
<channelSettings idleTimeout="1:0:0" maxItemsInCache="60"/>
<factorySettings idleTimeout="1:0:0" maxItemsInCache="60"/>
</sendMessageChannelCache>
</behavior>
</serviceBehaviors>
OperationContext 범위
기존의 코드 기반 서비스에서 들어오는 호출에 대 한 보안 정보는 OperationContext.Current를 통해 사용할 수 있습니다. WCF에서 디스패처 런타임은 서비스 메서드를 호출 하기 전에 스레드의 OperationContext를 설정 하므로 서비스 메서드 내에서 OperationContext.Current를 사용 하 여 보안 정보에 액세스할 수 있습니다.
WCF는 발송자와 워크플로 실행 중에 일련의 비동기 지점이 존재 하기 때문에 워크플로 서비스의 복잡성이 증가 합니다. 이러한 비동기 지점 중 하나에서 스레드를 전환할 수 있습니다. 이 경우 워크플로 논리 (활동)가 WCF의 스레드가 아닌 다른 스레드에서 실행 되 고 OperationContext.Current 기법을 이용 하 여 OperationContext 사용할 수 없게 됩니다. WF에서는 4 IReceiveMessageCallback와 ISendMessageCallback을 기반으로 하는 콜백 메커니즘을 사용 하 여 실행 되는 스레드와는 독립적으로 OperationContext에 대 한 액세스를 가능 하 게 합니다. IReceiveMessageCallback는 서버측, 클라이언트측 ISendMessageCallback OperationContext에 대 한 액세스를 가능 하 게 합니다. 서버 쪽에서 Receive 동작에서 메시지를 받은 후 즉시 IReceiveMessageCallback가 호출 됩니다. 이러한 콜백을 Send Receive 동작 및 작업에 연결 하려면 Send 및 Receive를 실행할 때 이러한 콜백을 실행 속성으로 사용할 수 있어야 합니다. 활동 실행 속성을 추가 하는 일반적인 방법은 부모 범위에 있는 작업을 만들고 실행 속성을 부모 작업 실행의 일부로 설정 하는 것입니다 (그림 3 참고).
그림 3실행 속성을 추가 하는 단순한 활동 범위
[ContentProperty("Body")]
public sealed class OperationContextScope : NativeActivity
{
public Activity Body { get; set; }
protected override void Execute(NativeActivityContext context)
{
if (this.Body != null)
{
// Adding an execution property to handle OperationContext
context.Properties.Add(OperationContextScopeProperty.Name,
new OperationContextScopeProperty());
context.ScheduleActivity(this.Body);
}
}
}
그림 3의 코드 조각은 OperationContextScope 활동의 런타임 실행 속성을 컨텍스트에 추가 하 여 모든 자식 활동을 실행 속성을 인식할 수 있도록 합니다.. Send 및 Receive 동작은 위에서 설명한 콜백 속성을 찾습니다. 이러한 속성 중 하나가 발견 되 면 적절 한 메시지 처리 단계에서이 속성을 호출 하 여 OperationContext에 액세스할 수 있습니다. 이 예에서는 동일한 범위에 있는 모든 받기 작업에서 OperationContextScopeProperty를 인식 하 고 OperationContext 값을 전달 하 여 콜백을 수행 합니다 (그림 4 참고).
그림 4실행 속성으로 구현 된 ReceiveMessageCallback
[DataContract]
class OperationContextScopeProperty : IReceiveMessageCallback, IExecutionProperty
{
private OperationContext current;
private OperationContext orignal;
public static readonly string Name =
typeof(OperationContextScopeProperty).FullName;
public void OnReceiveMessage(OperationContext operationContext,
ExecutionProperties activityExecutionProperties)
{
current = operationContext;
operationContext.OperationCompleted
+= delegate(object sender, EventArgs e)
{
current = null;
};
}
public void CleanupWorkflowThread()
{
OperationContext.Current = orignal;
}
public void SetupWorkflowThread()
{
orignal = OperationContext.Current;
OperationContext.Current = current;
}
}
OperationContextScopeProperty는 현재 활성 OperationContext 캡처 및 저장 하 고 나중에 WF TLS 메커니즘을 사용 하 여 적절 한 스레드에서 WF를 설정 합니다. IExecutionProperty 인터페이스는 SetupWorkflowThread 및 CleanUpWorkflowThread 메서드를 제공 합니다. 이제 모든 WF 작업 항목 (작업)의 실행 전과 후에 호출 되 고 선택 된 WF 스레드에서 여러 TLS 관련 속성을 설정할 수 있도록 합니다. 설정할 속성의 예로는 여기서 OperationContext입니다.
WF OperationContextScope 4 확장을 사용 하는 사용자 지정 작업의 예로는 실행 하는 스레드와는 독립적으로 해당 범위 내의 모든 하위 작업에 WCF OperationContext에 대 한 액세스를 가능 하 게 합니다.
워크플로 서비스와 WIF
WIF WCF 서비스를 ASP. 클레임 인식 응용 프로그램을 NET에서는 다양 한 API 및 개체 모델을 제공 합니다. WIF WCF와 호스트 수준에서 통합 되므로 WIF 기능의 대부분은 워크플로 서비스와 상호 작용 합니다. WIF와 워크플로 서비스 간의 통합에 대 한 내 블로그 기사 bit.ly/a6pWgA 영문)를 참조 하십시오. 이 기본 제공 통합은 기본적인 시나리오에서는 제대로 수행 되지만 기능이 추가 되는 시나리오를 활성화 하려면 WFSP 작업을 사용 합니다.
WFSP CTP 1 개요
WFSP Community Technology Preview (CTP) 1은 WF 4의 주요 보안 시나리오를 가능 하 게 하는 활동의 컬렉션 WCF와 관련 된 동작을 제공 합니다. WFSP은 ISendMessageCallback과 IReceiveMessageCallback의 확장 모델을 사용 하 여 다양 한 기능을 구현 합니다. WFSP의 CTP 1은 2010 년 7 월에 CodePlex에서 발표 (wf.codeplex.com/releases/view/48114 (영문 사이트)에서 다운로드 가능).
그림 5에서 볼 수 있는 WFSP 작업은 다른 WF와 잘 통합 되 고 워크플로 솔루션 통합 보안을 사용 함에 따른 강력한 구조를 제공 합니다.
.png)
그림 5Workflow Security Pack 활동
워크플로에서 승인
워크플로 서비스는 표준 WCF ServiceAuthorizationManager 확장을 사용 하 여 권한 부여를 적용 하 여 코드 기반 서비스와 동일한 방식으로 작동 합니다. 그러나 일부 시나리오 (예: 인증 데이터를 워크플로에 포함 된 경우에 해당)에서는 다음과 같은 작업을 수행할 때까지 승인 결정을 연기할 수 있습니다. PrincipalPermissionScope는 CLR PrincipalPermission 워크플로 승인 기능을 사용 함에 따른 서버 쪽 작업입니다. 범위에 있는 모든 하위 작업은 사용자 권한 요청이 성공한 경우에만 실행 됩니다. 이 동작은 OperationContext에서 액세스 되는 들어오는 WCF 보안 컨텍스트 내에서 ID 정보를 검색 합니다. PrincipalPermissionScope 문서 앞부분에서 설명한 것과 동일한 IReceiveMessageCallback 메커니즘을 사용 하 여 구현 됩니다.
실제 PrincipalPermission 요구는 ServiceAuthorizationBehavior.PrincipalPermissionMode 값을 기반으로 IPrincipal 개체에 대해 적용 됩니다. 이 확장 기능을 사용 하면 ASP와 PrincipalPermissionScope. NET 역할 공급자가 함께 작동 하 여 사용자 지정 IAuthorizationPolicy에 의해 생성 되는 사용자 지정 IPrincipal 구현을 모두 작동 합니다. WCF 서비스를 사용 하 여 ASP. NET 역할 공급자를 구성 하는 방법에 대 한 자세한는msdn.microsoft.com/library/aa702542 를 참조 하십시오.
메시징 활동과 인증할 메시징
보내기 작업은 워크플로 내에서 웹 서비스를 사용 하는 기본 방법을 제공 합니다. 대부분의 실제 시나리오에서는 이러한 백엔드 서비스가 보호 되므로 프로세스를 실행 하기 전에 인증을 받아야 합니다. 표준 코드 기반 서비스에서는 ChannelFactory 및 ClientBase <t>파생 된 프록시 클래스의 ClientCredential 속성을 사용 하 여 자격 증명을 지정 합니다. 이 속성을 사용 하 여 클라이언트가 서비스를 호출 하기 전에 사용할 자격 증명을 지정할 수 있습니다. 불행히도, ChannelFactory를 래핑하는 보내기 작업은 WF의 4 ClientCredential를 노출 하지 않기 때문에 명시적으로 자격 증명을 지정 해야 하는 일부 시나리오에는 보내기 작업을 사용할 수 없습니다. 보내기 작업은 구성 파일에서 끝점 동작 구성을 선택 하기 때문에 사용자 지정 끝점 동작을 만드는 경우에는 이러한 자격 증명을 지정할 수 있습니다.
명시적 자격 증명을 요구 하는 대표적인 예는 사용자 이름과 암호를 요구 하도록 구성 된 서비스를 호출 하는 것입니다. ClientCredential 속성은 보내기 작업으로 노출 되지 않기 때문에 사용자 이름과 암호를 지정할 수 없습니다. 에서이 시나리오와 관련 된 다른 시나리오에 대 한 GetUserNameSecurityToken WFSP의 활동에 어떤 해결책을 제공 하는 방법을 살펴보겠습니다.
In 그림 6 ,서비스 참조 추가 마법사에서 Ping 작업을 생성 하 고 있습니다. 다음 바인딩 구성에 나와 있는 것 처럼 사용자 이름을 사용 하 여 인증을 요구 함으로써 보안 서비스를 호출 하도록 구성 합니다.
<wsHttpBinding>
<binding name="singleShotUserName">
<security mode="Message">
<message clientCredentialType="UserName" establishSecurityContext
="false" />
</security>
</binding>
</wsHttpBinding>
.png)
그림 6UserName 토큰을 사용 하 여 인증할 메시징
위에서 설명한 워크플로는 GetUserNameSecurityToken 여기에 지정 된 사용자 이름 및 암호를 기준으로 UserNameSecurityToken 만들기 및 TokenFlowScope 작업에 의해 제공 되는 환경에 대 한 SecurityTokenHandle 토큰을 등록 합니다. "Workflow Security Pack"보안 자격 증명의 수준에서 적용 하는 ClientBase ChannelFactory 및 <t>접근과는 대조적으로 SecurityToken 수준에서 보안을 적용 합니다. 표준 WCF에서 보안 토큰을 만드는 데 필요한 자격 증명을 사용 하는 반면, WFSP는 보안 토큰을 직접 사용 하 여 자격 증명 토큰 수준이 아닌 수준에서 WCF 보안 계층과 통신 합니다.
TokenFlowScope 인증을 받는 등 재미 있는 메시징 시나리오를 가능 하 게 하는 중요 한 작업입니다. 이 작업은 WorkflowClientCredentials 끝점 동작과 함께 등록 된 토큰을 워크플로 계층에서 WCF 보안 계층으로 전달 합니다. WCF 보안 계층은 끝점의 바인딩 요청 마다 이러한 토큰을 메시지에 첨부 합니다. TokenFlowScope에서는 다음과 같은 구성 조각에서 볼 수 있듯이 사용자 지정 동작의 ClientCredential (WorkflowClientCredentials)를 구성 해야 합니다.
<behavior>
<!--This custom clientCredentials enables the credential flow from
workflow data model into WCF security layer. -->
<clientCredentials
type="Microsoft.Security.Activities.WorkflowClientCredentials,
Microsoft.Security.Activities, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35">
</clientCredentials>
</behavior>
WFSP는 보안 토큰 서비스 (STS) 로부터 토큰을 필요로 하는 서비스를 호출 하는 경우이 엄격한 모델에 따릅니다 (그림 7 참고).
.png)
그림 7SAML 토큰을 가져오고 용도 세분화 된 제어
In 그림 7,에서는 GetSamlSecurityToken와 게시자가 되 고 SAML 토큰을 얻습니다. 그런 다음이 토큰을 TokenFlowScope 작업에 의해 제공 되는 환경 핸들에 등록 됩니다. 이러한 등록은 동일한 범위에 있어야 하 고 SAML 토큰을 요청 하는 모든 Send 동작에이 토큰을 사용할 수 있습니다. 이 모델은 확장 가능 하므로, 예를 들어, SAML 토큰을 반환할 때 STS는 UserName 토큰을 필요로 하 고 유효한 UserName 토큰이 범위에 이미 등록 되어 있는 경우에는 SAML 토큰을 반환 하는 반면, GetSamlSecurityToken 등록 된 토큰을 사용할 수 있습니다. WorkflowClientCredentials 동작을 구성 하 여 SAML 토큰을 요청 하는 경우 GetSamlSecurityToken가이 토큰을 사용 하도록 설정 됩니다.
기본 제공 되는 WFSP는 토큰 형식으로 UserName과 SAML만 지원 하지 않습니다. 그러나 GetSecurityToken 클래스에서 상속 하 여 다른 유형의 토큰을 사용할 수 있습니다 (그림 8 코드 예제 참조). GetSecurityToken 클래스는 X509 토큰 기반을 만들기 위한 작업을 구현 합니다.
Figure 8 WFSP Extensibility: Implementing Additional Token Types
[Designer(typeof(GetX509SecurityTokenDesigner))]
public class GetX509SecurityToken : GetSecurityToken
{
public GetX509SecurityToken()
{
FindType = X509FindType.FindBySubjectName;
StoreLocation = StoreLocation.CurrentUser;
StoreName = StoreName.My;
}
public InArgument<X509Certificate2> Certificate { get; set; }
public X509FindType FindType { get; set; }
public StoreLocation StoreLocation { get; set; }
public InArgument<string> FindValue { get; set; }
public StoreName StoreName { get; set; }
protected override void Execute(NativeActivityContext context)
{
X509Certificate2 targetCert = null;
if (this.Certificate != null)
targetCert = this.Certificate.Get(context);
if (targetCert == null)
{
var store = new X509Store(StoreName, StoreLocation);
try
{
store.Open(OpenFlags.ReadOnly);
var col = store.Certificates.Find(FindType, FindValue.Get(context), false);
if (col.Count > 0)
targetCert = col[0];//Use first certificate mathing the search criteria
}
finally
{
if (store != null)
store.Close();
}
}
if (targetCert == null)
throw new InvalidOperationException(
"No certificate found using the specified find criteria.");
// Enlist the token as a flow token
base.EnlistSecurityToken(context, new X509SecurityToken(targetCert));
}
}
GetX509SecurityToken은 자격 증명을 기반으로 X509Security 토큰을 만들고이 토큰을 토큰으로 흐름 SecurityTokenHandle에 등록 하십시오. 이 토큰은 인증을 위해 인증서가 필요한 서비스를 호출 하는 데 사용할 수 있습니다. Figure 9 shows GetX509SecurityToken in use with a custom activity designer.
.png)
그림 9TokenFlowScope 및 GetToken 활동
클레임 기반 권한 위임
클레임 기반 위임은 WFSP에서 가능 하 게 된 또 다른 유용한 기능입니다. 클레임 기반 위임 워크플로 서비스를 위해 더 좋은 경우가 많습니다. 재프로그래밍, 워크플로 서비스는 기본적으로 여러 대의 백 엔드 서비스 호출 오케스트레이션/비즈니스 프로세스를 구현 하기 위해서입니다. 또한 대부분의 경우 세부적인 권한 부여 결정을 가능 하 게 하기 위해 이러한 백 엔드 서비스는 호출자의 ID에 대 한 액세스가 필요 합니다. WFSP는 WS-Trust 1.4의 ActAs 기능을 활용 하 여 모든 종류의 ActAs 토큰을 토큰으로 사용 하도록 할 수 있습니다. 기본적으로 모든 활동이 GetToken 토큰을 만들고 해당 토큰이 흐름 토큰으로 등록 합니다. 그러나 이러한 모든 작업에는 IsActAsToken 라는 플래그도 포함 됩니다 (그림 10 참고).
.png)
그림 10ActAs 토큰 만들기
이 플래그의 확인란을 선택 하면 토큰 생성 논리는 변경 되지 않고 결과 토큰 T1이 흐름 토큰 대신 ActAs 토큰으로 등록 됩니다. ActAs 토큰을 범위 당 하나만 SAML 토큰을 요청 하는 경우 GetSamlSecurityToken 작업에 의해 사용 됩니다. GetSamlSecurityToken를 실행할 때 활성 ActAs 토큰을 선택 하 고 GetSamlSecurityToken 작업에 의해 생성 된 토큰 발급 요청의 일부로 전송 됩니다. 반환 된 토큰 T2는 인증 토큰 및 ActAs 토큰에서 클레임을 볼 수 있습니다. 마지막으로, 보안 컨텍스트에서 두 ID를 백 엔드 서비스를 호출할 때이 범위 내에서 실행 되는 Send 동작에이 T2 토큰을 사용할 수 있습니다.
GetBootstrapToken 활동, 중간 계층 시나리오에서 종단 간 클레임 기반 위임을 제공 합니다. GetToken 동작과는 달리이 동작은 새 토큰을 만들어 등록 하는 것 보다는 들어오는 토큰을 읽고 ActAs 토큰을 토큰으로 등록 합니다. GetBootstrapToken 활동을 통해 워크플로 서비스는 백 엔드 서비스를 호출할 때 고유한 ID 이외에 들어오는 호출자 ID를 사용할 수도 있습니다 (그림 11 참고).
.png)
그림 11종단 클레임 기반 위임의 흐름
그림 11의 3 단계워크플로 서비스는 WFSP 작업을 사용 하 여 들어오는 토큰을 읽은 부트스트래퍼 부트스트래퍼 토큰의 ID로 사용 되는 새 토큰을 검색 하 여 두 ID를 백 엔드 서버로 전달 합니다. 그림 12이 워크플로 서비스에 사용 되는 워크플로를 나타냅니다.
.png)
그림 12클레임 기반 위임 워크플로
그림 12의 워크플로에서는 GetBootstrap 활동이 OperationContextScope에 배치 되 고이 작업을 수행할 때 실행 되는 것과는 상관 없이 OperationContext에 대 한 액세스가 보장 됩니다. GetSamlSecurityToken는 이전 단계에서 GetBootstrapToken에 의해 생성 된 ActAs 토큰을 사용 하 여, 궁극적으로, GetSamlSecurityToken 작업에 의해 생성 된 최종 SAML 토큰을 사용 하 여 Echo 활동에서 백 엔드 서비스를 호출 합니다.
Windows의 가장 및 위임
ImpersonatingReceiveScope는 서버 사이드의 또 다른 활동입니다. 이를 통해 Windows 워크플로 환경에서 가장 및 위임 기능이 제공 됩니다. 이 작업을 수행할 때 들어오는 보안 컨텍스트 내에서 WindowsIdentity를 찾습니다. 들어오는 메시지에서 WindowsIdentity를 생성 하는 경우 가장 된 범위 내에서 본문에 포함 된 모든 하위 작업이 실행 됩니다. ImpersonatingReceiveScope는이 문서의 앞부분에서 설명한 워크플로 TLS 메커니즘을 사용 하 여 작업 항목을 실행 하기 바로 전에, WF의 스레드 ID를 가장 합니다. 가장은 WF 작업 항목의 실행이 완료 된 후 실행 취소 됩니다.
들어오는 보안 컨텍스트 내에서 유효한 WindowsIdentity를 찾을 수 없다면, ImpersonatingReceiveScope는 WIF ID (Thread.CurrentPrincipal) 또는 일반적인 WCF ClaimSet에서 UPN 클레임을 찾아 사용 하 여 Kerberos S4U 기능을 사용 하는 WindowsToken를 만듭니다. UPN 클레임을 Windows 토큰을 대체 하기 위해 ImpersonatingReceiveScope은 "Claims to Windows Token Service"에 따라 달라 집니다. 이것은 런타임의 WIF 일부입니다. 클레임 토큰으로 변환을 성공적으로 완료 하려면이 서비스가 설치 되어 실행 되 고 있어야 합니다.
그림 13 , ImpersonatingReceiveScope 활동의 일반적인 사용법을 보여 줍니다.
.png)
그림 13에서 실행 되는 ImpersonatingRecieveScope
종단 보안
보기 만으로는, 워크플로우 서비스는 표준 WCF 서비스 이기 때문에 WCF의 대부분의 보안 옵션을 워크플로 서비스에도 적용할 수 있습니다. 4 WF에서는 워크플로 서비스의 보안 경계를 워크플로 계층까지 확장 하는 데 사용할 수 있는 주요 확장 지점이 다 수 도입 되었습니다. WFSP는 이러한 확장 지점을 사용 하 여 WF 4에서 종단 간 보안을 제공 하는 일련의 활동을 제공 합니다.
Zulfiqar Ahmed 는 고급 지원 팀의 수석 컨설턴트로, Workflow Security Pack 프로젝트 작성자 이기도 합니다. 그는 의 블로그 zamd.net (영문 사이트)에 있습니다. 이 블로그에서는 Windows Communication Foundation, Windows Workflow Foundation 및 클레임 기반 보안에서 일반적인 Microsoft. NET Framework에 대 한 문서에 이르기까지 다양 한 주제를 다룹니다..
이 게시물의 리뷰를 위해 협력해 주신 의 기술 인력 Dave Cliffe 에 진심으로 감사 드립니다.