WCF 4.0의 WCF REST Starter Kit의 RequestInterceptor와 유사합니까?

StackOverflow https://stackoverflow.com/questions/6023121

  •  14-11-2019
  •  | 
  •  

문제

WCF 4.0에는 WCF REST Starter Kit의 RequestInterceptor에 대한 아날로그 클래스/모듈 등이 있습니까?

도움이 되었습니까?

해결책

1-1에 매핑되는 것은 없지만 WCF 코어에서 IDispatchMessageInspector를 사용하여 요청 인스 펙터가 수행하는 대부분의 시나리오를 구현할 수 있습니다. http : //blogs.msdn.com/b/carlosfigueira/archive/2011/04/19/wcf-extensibility-message-inspectors.aspx 메시지 검사기에 대한 몇 가지 자세한 정보가 있습니다.

다른 팁

업데이트를 가지고 돌아왔습니다.

나는 코드의 단순성을 중요하게 생각하며 이 문제를 성공적으로 해결한 후에는 쿼리 문자열 방법보다 더 선호한다고 말할 수 없습니다.AuthZ 메서드와 함께 AuthN 메서드를 호출하는 각 서비스 엔드포인트에 단일 호출을 삭제하는 것은 일부 사람들이 생각하는 것보다 쉬워 보입니다.

어쨌든, 해결책에 대한 의견은 충분합니다.해결책은 이 링크의 Stackoverflow 바로 아래에 있지만 우리의 맥락에서는 잘 설명되어 있지 않습니다. 따라서 여기에 있는 샘플 코드에 대해 "user634119"를 인정하겠습니다.OperationContext의 헤더

먼저 web.config 파일에 serviceBehavior를 추가해야 합니다.

<behaviors>
  <serviceBehaviors>
    <behavior>
      <serviceAuthenticationManager serviceAuthenticationManagerType="WCF.BasicAuthorization, WCF"></serviceAuthenticationManager>
      <serviceAuthorization impersonateCallerForAllOperations="false" principalPermissionMode="Custom" serviceAuthorizationManagerType="WCF.BasicAuthentication, WCF">
      </serviceAuthorization>
    </behavior>
  </serviceBehaviors>
</behaviors>

다음으로 클래스를 만듭니다(위의 serviceBehaviors 블록에서 참조된 BasicAuthorization이라고 함).

//Authorize the call against the URI resource being requested...
public class BasicAuthorization : ServiceAuthorizationManager
{
    public override bool CheckAccess(OperationContext operationContext, 
    ref Message message)
    {
        //some code
    }
}

다음으로 인증 클래스를 만듭니다.

// Authenticate the header signature as described in my previous post
public class BasicAuthentication : ServiceAuthenticationManager
{
    public override ReadOnlyCollection<IAuthorizationPolicy> Authenticate(
        ReadOnlyCollection<IAuthorizationPolicy> authPolicy, Uri listenUri, 
        ref Message message)
    {
        //some code
    }
}

Authenticate 메서드에서 HttpRequestMessageProperty를 사용하여 요청 헤더 세부 정보를 가져오고 첫 번째 응답에 설명된 것과 동일한 3단계를 수행합니다.

에두아르도, 당신은 이렇게 물었습니다.@carlosfigueira:인증 하위 시스템을 구현하는 데 사용할 수 있나요?

나는 동일한 문제에 대해 작업 중이며 귀하를 위한 하나 이상의 솔루션(아래 설명)과 곧 출시될 인증 헤더 기반 솔루션(귀하가 "가로채기"를 생각하고 있는 솔루션이라고 믿습니다)이 있습니다.

WCF 4 REST WebHttp 프로그래밍 모델 기반 끝점을 보호하는 가장 간단한 방법은 다음과 같습니다.

  1. 자격 증명으로 사용할 공유 비밀 키와 API 키를 각 클라이언트에 발급합니다.API 키는 실제로 사용자 이름과 동일합니다.
  2. SSL을 통해 모든 엔드포인트를 실행하여 항상 채널/메시지/데이터 보안을 유지하세요.
  3. 클라이언트가 공유 비밀을 사용하여 타임스탬프와 API 키가 포함된 HMAC-SHA1(또는 동등한) 해시 서명 문자열을 생성하도록 요구합니다.
  4. 클라이언트가 이 세 가지를 모두 쿼리 문자열 매개변수로 전달하도록 요구합니다. 모든 요청에:
  5. 서비스 측에서 3개의 문자열을 모두 사용하는 인증 방법을 구현한 후 다음을 수행합니다.
    • API 키를 조회하고 클라이언트의 공유 비밀을 반환합니다. 너 DB나 다른 곳에 있어요.
    • 재생 공격을 방지하기 위해 타임스탬프를 DateTime.Now와 비교하여 요청이 15분을 넘지 않았는지 확인하세요.
    • 이 3개의 문자열을 사용하여 서명 문자열을 다시 만들고 클라이언트가 전달한 서명 문자열과 비교하세요.
    • 일치하면 요청자가 진짜입니다.

이제 이를 수행하는 더 좋은 방법은 HTTP 인증 요청 헤더를 사용하여 해당 3개의 문자열을 저장하고 글로벌 인터셉터 같은 프로세스가 모든 요청을 감시하도록 하는 것입니다.이렇게 하면 인증 블록 없이 엔드포인트가 노출될 가능성이 방지됩니다(적어도 그럴 가능성은 낮습니다).

이 모든 정보를 전달하기 위해 쿼리 문자열을 사용할 때의 문제는 쿼리 문자열의 최대 길이가 2k(클라이언트/브라우저에 따라 다름)이고 디버깅할 때 쿼리 문자열을 읽기가 정말 어렵다는 것입니다. 하지만 익숙해지면 됩니다.

어떤 사람들은 이를 수행하는 보다 정교한 방법이 클라이언트가 이러한 3가지 인증 문자열을 보안 토큰 서비스 끝점에 전달하도록 요구하는 STS 모델이라고 생각합니다.응답 메시지는 3개의 문자열 대신 클라이언트가 각 호출에 전달하는 세션 토큰을 다시 전달합니다.클라이언트의 경우 각 호출마다 HMAC 해시 서명을 생성할 필요가 없다는 것은 사실이지만 서버 측에서는 여전히 토큰을 인증해야 하며 세션 개념이 깔끔한 RESTful 상태 비저장 동작을 방해합니다.

쿼리 문자열과 인증 헤더 방법론을 모두 구현하는 코드 블록을 게시하기 위해 최선을 다하겠습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top