지원되지 않는 시나리오
여러 가지 이유로 WCF(Windows Communication Foundation)에서는 일부 특정 보안 시나리오를 지원하지 않습니다. 예를 들어, Windows XP Home Edition에서는 SSPI 또는 Kerberos 인증 프로토콜을 구현하지 않으므로 WCF에서는 해당 플랫폼에서 Windows 인증을 통한 서비스 실행을 지원하지 않습니다. Windows XP Home Edition에서 WCF를 실행할 경우 사용자 이름/암호 및 HTTP/HTTPS 통합 인증과 같은 다른 인증 메커니즘이 지원됩니다.
가장 시나리오
Windows XP 및 보안 컨텍스트 토큰 쿠키 사용
다음과 같은 조건에서는 WCF에서 가장을 지원하지 않고 InvalidOperationException이 throw됩니다.
- 운영 체제가 Windows XP인 경우
- 인증 모드에서 Windows ID를 생성하는 경우
- OperationBehaviorAttribute의 Impersonation 속성이 Required로 설정된 경우
- 상태 기반 SCT(보안 컨텍스트 토큰)가 만들어지는 경우(기본값: 만들기 사용 안 함)
상태 기반 SCT는 사용자 지정 바인딩을 통해서만 만들 수 있습니다. 자세한 내용은 방법: 보안 세션에 대한 상태 저장 보안 컨텍스트 토큰 만들기를 참조하십시오. 코드에서 System.ServiceModel.Channels.SecurityBindingElement.CreateSspiNegotiationBindingElement(System.Boolean) 또는 System.ServiceModel.Channels.SecurityBindingElement.CreateSecureConversationBindingElement(System.ServiceModel.Channels.SecurityBindingElement,System.Boolean) 메서드를 사용하여 보안 바인딩 요소(SymmetricSecurityBindingElement 또는 AsymmetricSecurityBindingElement)를 만들고 requireCancellation 매개 변수를 false로 설정하여 토큰을 사용하도록 설정합니다. 매개 변수는 SCT 캐싱을 참조합니다. 값을 false로 설정하면 상태 기반 SCT 기능을 사용할 수 있습니다.
또는 구성에서 <customBinding>을 만든 다음 <security> 요소를 추가하고 authenticationMode 특성을 SecureConversation으로 설정하고 requireSecurityContextCancellation 특성을 true로 설정하여 토큰을 사용하도록 설정합니다.
참고
앞의 요구 사항은 각기 고유합니다. 예를 들어, CreateKerberosBindingElement는 Windows ID를 생성하는 바인딩 요소를 만들지만 SCT를 설정하지 않습니다. 따라서 Windows XP에서 Required 옵션을 설정하여 사용할 수 있습니다.
가능한 ASP.NET 충돌
WCF 및 ASP.NET에서는 가장을 사용하거나 사용하지 않도록 설정할 수 있습니다. ASP.NET에서 WCF 응용 프로그램을 호스팅하면 WCF 및 ASP.NET 구성 설정 간에 충돌이 발생할 수 있습니다. 충돌이 발생할 경우 Impersonation 속성이 NotAllowed로 설정되어 있으면 ASP.NET 가장 설정이 우선하고, 그렇지 않으면 WCF 설정이 우선합니다.
가장에서 어셈블리 로드 실패
가장 컨텍스트에 어셈블리 로드 액세스 권한이 없고 CLR(공용 언어 런타임)에서 AppDomain에 대한 어셈블리 로드를 처음으로 시도하는 경우 AppDomain은 오류를 캐시합니다. 가장을 변환한 이후 변환된 컨텍스트에 어셈블리 로드 액세스 권한이 있더라도 후속 어셈블리 로드 시도는 실패합니다. CLR은 사용자 컨텍스트가 변경된 이후에 로드를 다시 시도하지 않기 때문입니다. 오류를 복구하려면 응용 프로그램 도메인을 다시 시작해야 합니다.
참고
WindowsClientCredential 클래스의 AllowedImpersonationLevel 속성 기본값은 Identification입니다. 대부분의 경우 확인 수준 가장 컨텍스트에는 추가 어셈블리 로드 권한이 없습니다. 이는 기본값이므로 일반적인 조건으로 알아 두어야 합니다. 확인 수준 가장은 가장 프로세스에 SeImpersonate 권한이 없는 경우에도 발생합니다. 자세한 내용은 WCF를 통한 위임 및 가장을 참조하십시오.
위임에 자격 증명 협상 필요
Kerberos 인증 프로토콜을 위임과 함께 사용하려면 자격 증명 협상이 포함된 Kerberos 프로토콜(multi-leg 또는 multi-step Kerberos라고도 함)을 구현해야 합니다. 자격 증명 협상이 포함되지 않은 Kerberos 인증(one-shot 또는 single-leg Kerberos라고도 함)을 구현하면 예외가 throw됩니다. 자격 증명 협상을 구현하는 방법에 대한 자세한 내용은 Windows 인증 오류 디버깅을 참조하십시오.
암호화
대칭 키 사용에만 SHA-256 지원됨
WCF에서는 시스템 제공 바인딩에서 알고리즘 모음을 사용하여 지정할 수 있는 다양한 암호화 및 서명 다이제스트 만들기 알고리즘을 지원합니다. 향상된 보안을 위해 WCF에서는 서명 다이제스트 해시를 만드는 데 SHA(Secure Hash Algorithm) 2 알고리즘 특히 SHA-256을 지원합니다. 이 릴리스에서는 Kerberos 키와 같은 대칭 키 사용에만 SHA-256을 지원합니다. 여기서는 X.509 인증서가 메시지를 서명하는 데 사용되지 않습니다. .NET Framework 3.0에서는 현재 RSA-SHA256을 지원하지 않기 때문에 WCF에서 SHA-256 해시를 통한 RSA 서명(X.509 인증서에 사용됨)을 지원하지 않습니다.
FIPS 규격 SHA-256 해시 지원되지 않음
WCF에서는 SHA-256 FIPS 규격 해시를 지원하지 않기 때문에 SHA-256을 사용하는 알고리즘 모음은 FIPS 규격 알고리즘을 사용해야 하는 시스템의 WCF에서 지원되지 않습니다.
레지스트리 편집 시 FIPS 규격 알고리즘 실패
로컬 보안 설정 MMC(Microsoft Management Console) 스냅인을 사용하여 FIPS(Federal Information Processing Standards) 규격 알고리즘을 사용하거나 사용하지 않도록 설정할 수 있습니다. 레지스트리에서 설정에 액세스할 수도 있습니다. 그러나 WCF에서는 레지스트리를 사용하여 설정을 다시 설정할 수 없습니다. 1 또는 0 이외의 값을 설정하면 CLR과 운영 체제 간에 일치하지 않는 결과가 발생할 수 있습니다.
FIPS 규격 AES 암호화 제한
FIPS 규격 AES 암호화는 확인 수준 가장의 이중 콜백에서 작동하지 않습니다.
Windows Server 2008에서 CNG/KSP 인증서
*CNG(Cryptography API: Next Generation)*는 CryptoAPI를 장기적으로 대체하는 API입니다. 이 API는 Windows Vista 및 Windows Server 2008에서 비관리 코드로 사용할 수 있습니다.
하위 수준 플랫폼(Windows Server 2003 및 Windows XP)에서는 .NET Framework 2.0이 이 프로토콜을 인식하지 않으므로 대신 레거시 CryptoApi를 사용하여 CNG/KSP 인증서를 처리합니다. Windows Server 2008 및 Windows Vista에서는 .NET Framework 3.5가 이러한 인증서를 지원하지 않으므로 사용할 경우 예외가 발생합니다.
인증서에서 KSP를 사용하는지 여부를 파악하는 방법은 다음 두 가지입니다.
- CertGetCertificateContextProperty에 대해 p/invoke를 실행하고 반환되는 CertGetCertificateContextProperty에서 dwProvType이 있는지 확인합니다.
- 명령줄에서 certutil 명령을 사용하여 인증서를 쿼리합니다. 자세한 내용은 인증서 문제 해결을 위한 Certutil 작업(영문 페이지일 수 있음)을 참조하십시오.
ASP.NET 가장 및 ASP.NET 호환성을 사용해야 하는 경우 메시지 보안 실패
WCF에서 다음과 같은 설정은 클라이언트 인증을 방해할 수 있으므로 지원되지 않습니다.
- ASP.NET 가장이 사용됩니다. 이 작업은 Web.config 파일에서 <identity> 요소의 impersonate 특성을 true로 설정하여 수행합니다.
- ASP.NET 호환성 모드는 <serviceHostingEnvironment> element의 aspNetCompatibilityEnabled 특성을 true로 설정하여 지정합니다.
- 메시지 모드 보안이 사용됩니다.
ASP.NET 호환성 모드를 해제하면 문제가 해결됩니다. 또는 ASP.NET 호환성 모드를 사용해야 하는 경우 ASP.NET 가장 기능을 사용하지 않도록 설정하고 WCF 제공 가장을 대신 사용합니다. 자세한 내용은 WCF를 통한 위임 및 가장를 참조하십시오.
IPv6 리터럴 주소 오류
클라이언트와 서비스가 동일한 컴퓨터에 있고 IPv6 리터럴 주소가 서비스에 사용되는 경우 보안 요청이 실패합니다.
리터럴 IPv6 주소는 서비스와 클라이언트가 서로 다른 컴퓨터에 있는 경우에 작동됩니다.
페더레이션 신뢰에서 WSDL 검색 오류
WCF에서는 페더레이션 신뢰 체인의 각 노드에 대해 정확히 하나의 WSDL 문서가 있어야 합니다. 끝점을 지정할 때 루프를 설정하지 않도록 주의해야 합니다. 루프를 발생시킬 수 있는 한 가지 방법은 같은 WSDL 문서에 두 개 이상의 링크가 포함된 페더레이션 신뢰 체인에 대해 WSDL 다운로드를 사용하는 것입니다. 이 문제를 일으킬 수 있는 일반적인 시나리오로 보안 토큰 서버와 서비스가 동일한 ServiceHost 내에 포함된 페더레이션 서비스를 들 수 있습니다.
다음과 같은 세 끝점 주소가 있는 서비스를 이러한 상황의 예로 들 수 있습니다.
- https://localhost/CalculatorService/service(서비스)
- https://localhost/CalculatorService/issue_ticket(STS)
- https://localhost/CalculatorService/mex(메타데이터 끝점)
이 경우 예외가 throw됩니다.
issue_ticket 끝점을 다른 곳에 넣어 이 시나리오가 작동하게 만들 수 있습니다.
WSDL 가져오기 특성이 손실될 수 있음
WSDL 가져오기를 실행할 때는 WCF에서 RST 템플릿의 <wst:Claims> 요소에 대한 특성을 추적하지 않게 됩니다. WSDL 가져오기 중에 클레임 형식 컬렉션을 직접 사용하지 않고 WSFederationHttpBinding.Security.Message.TokenRequestParameters 또는 IssuedSecurityTokenRequestParameters.AdditionalRequestParameters에서 직접 **<Claims>**를 지정하는 경우에 이 문제가 발생합니다. 가져오기 중에 특성이 손실되므로 바인딩이 WSDL을 통해 제대로 라운드트립되지 않고 클라이언트측에서 잘못됩니다.
문제를 해결하려면 가져오기를 실행한 후 클라이언트에서 직접 바인딩을 수정합니다.