2012-07-17 2 views
3

우리는 핵심 API를 수용하기 위해 WCF 서비스를 개발 중입니다.WCF 및 다중 보안 모델

우리는이 API를 사용하기 위해 2 개의 클라이언트를 작업 중입니다. 그 중 하나는 액티브 디렉토리에 대해 인증하고 API와 동일한 도메인에 상주하는 WPF 데스크톱 응용 프로그램입니다. 다른 하나는 보안을 위해 ASP.Net Membership을 사용하고 WCF 서비스와 동일한 도메인에 상주 할 ASP.Net 웹 응용 프로그램입니다. 이 계획은 WCF 서비스가 NetTcp를 사용하고 Windows 서비스 내에서 호스팅 될 계획입니다.

가능한 경우 호출 사용자로 WCF 서비스를 실행하고 싶습니다. 사용자가 도메인 사용자 인 데스크톱 응용 프로그램의 경우 상당히 간단합니다. 웹 응용 프로그램에 대한 서비스 호출에 대한 사용자를 만들 필요가있을 것 같아요.

단일 WCF 서비스에서 실행되는 보안에 대한 이러한 종류의 이중 접근 방식을 얻는 것이 가능합니까? 아니면 자체 보안 모델로 각각 2 개의 서비스를 만들어야합니까?

다른 사람이이를 달성하기위한 모범 사례/패턴에 대한 생각을 갖고 있다면 좋을 것입니다. 나는 다음과 같은 방법으로 같은 문제를 해결했습니다

+0

보안은 [끝점에 적용]됩니다 (http://msdn.microsoft.com/en-us/library/ms731199.aspx). 그렇다면 자체 보안 매개 변수가있는 여러 끝점을 추가하여 동일한 서비스. [다른 사람] (http://msdn.microsoft.com/en-us/library/ms730088.aspx)을보고 외부 사용자를 다른 사람으로 실행할 수있게하십시오. – CodeCaster

답변

4

감사합니다 :

  1. 나는 모든 사용에 대한 구속력이 net.tcp를 만들었습니다. 클래스 -

    <security mode="TransportWithMessageCredential"> 
        <transport clientCredentialType="" /> 
        <message clientCredentialType="UserName" /> 
        </security> 
    
    </binding> 
    <binding name="WindowsBinding" > 
    
        <security mode="TransportWithMessageCredential"> 
        <transport clientCredentialType="Windows" /> 
        </security> 
    
    </binding> 
    

  2. 다음, 나는 모든 서비스

    <service name="SimplePluginService" behaviorConfiguration="CommonBehavior"> 
    
        <endpoint binding="netTcpBinding" bindingConfiguration="UserNameBinding" name="SimplePluginServiceUserName" contract="ISimplePluginService"> 
         <identity> 
          <dns value="WCfServer" /> 
         </identity> 
        </endpoint> 
    
        <endpoint binding="netTcpBinding" bindingConfiguration="WindowsBinding" name="SimplePluginServiceWindows" contract="ISimplePluginService"> 
         <identity> 
          <dns value="WCfServer" /> 
         </identity> 
        </endpoint> 
    
    </service> 
    
  3. 다음 두 개의 엔드 포인트를 추가, 나는 ChannelFactory에 (은 ConnectionManager를 만들 때 적절한 엔드 포인트를 choosed 할 여기에는 사용자의 신용 정보가 들어 있습니다).

    private readonly Dictionary<Type, Object> channelFactoryDictionary = new Dictionary<Type, Object>(); 
    
    private ChannelFactory<T> GetChannelFactory<T>() where T : class 
    { 
        if (channelFactoryDictionary.Keys.Contains(typeof(T))) 
        { 
         return channelFactoryDictionary[typeof(T)] as ChannelFactory<T>; 
        } 
        else 
        { 
         string endpointName=typeof(T).ToString(); 
         if (ConnectionManager.IsWindowsAuth) endpointName+="Windows"; 
         else endpointName+="UserName"; 
    
         ChannelFactory<T> channelFactory = new ChannelFactory<T>(endpointName); 
    
         if (!ConnectionManager.IsWindowsAuth){ 
          channelFactory.Credentials.UserName.UserName = ConnectionManager.Password; 
          channelFactory.Credentials.UserName.Password = ConnectionManager.Password; 
         } 
    
         channelFactoryDictionary.Add(typeof(T), channelFactory); 
         return channelFactory; 
        } 
    } 
    
0

당신은 여기에 몇 가지 문제를 가미하여 있습니다. 첫째, ASP.NET 멤버십에 의존하기를 원하지 않는 한, 호스팅 (Windows 서비스)과 전송 (여기서는 netTcp로 지정)은 인증/권한 부여 선택과 관련이 없다고 주장합니다. 서비스를 호스팅 할 IIS입니다.

데스크톱 또는 신중하게 계획된 LDAP 환경에서 가장에 대한 액세스가 확실한 방법입니다. 그래도 내 서비스가 커짐에 따라 비즈니스 요구 사항이 Active Directory에 표시되는 정책에서 벗어나는 경향이 있습니다. 그런 일이 발생하면 서비스가 Windows 흉내를 원하는대로 유지하기 위해 더 많은 지원을 요구하기 시작합니다. 이는 종종 WCF 확장 성을 다루는 것을 의미합니다.

수년 간의 경험으로 말하자면, WCF 보안 확장 포인트를 사용하는 것은 거의 마취되지 않은 근관만큼 고통 스럽습니다. 그것은 고통스런 일이 끝나면 꽤 강력하다고 말했다.

나는 일반적으로 통증이 적다는 것을 발견했다. 내 코드에서 액세스 제한을 명시 적으로 모델링하여 가장 (impersonation)의 보안 이점을 얻을 수 있습니다. 클레임 기반 보안 및 CAS 특성을 사용합니다.이러한 접근 방식을 취하면 커스텀 클래스는 가장 (impersonation)의 필요성을 없앨 수 있으며, 그로 인해 모호한 WCF 위생 (plumbing)을 피할 수 있습니다.

당신이 찾고 있던 대답은 아니지만, 그럼에도 불구하고이 두 가지 센트입니다.