1. 程式人生 > >快速入門系列--WCF--07傳輸安全、授權與審核

快速入門系列--WCF--07傳輸安全、授權與審核

最大的 緩存 ims cut 常見 曾經 strong 這一 set

這部分主要涉及企業級應用的安全問題,一般來說安全框架主要提供3個典型的安全行為:認證、授權和審核。除了典型的安全問題,對於一個以消息作為通信手段的分布式應用,還需要考慮消息保護(Message Protection)問題,消息保護機制主要包括簽名和加密,前者保證消息的一致性,後者保證消息的機密性。

技術分享

在介紹傳輸安全之前,介紹幾個在分布式應用中常見的傳輸安全隱患:消息的篡改,敏感信息的泄露,釣魚攻擊,重放攻擊。因此對於WCF來說,其傳輸安全主要涉及認證、消息一致性和機密性三個主題,認證不僅包括服務器對客戶端的認證,也包括客戶端對服務的身份驗證,即雙向驗證,消息一致性保證消息的內容在傳輸過程中不被篡改,機密性確保只有希望的消息接收方才能讀取其中內容。WCF為了應對這些問題,提供了兩種不同的安全模式,Transport安全和Message安全。

Transport安全:基於傳輸層協議的安全機制,其中TLS/SSL是最常用的方式,常說的HTTPS其實就是將HTTP和TLS/SSL結合在一起,對於WCF來說,所有的基於HTTP協議的綁定在采用Transport安全的情況,對於NetTcpBinding來說,也同樣支持,即組合使用TCP和TLS/SSL。該協議體系可以解決如下兩個問題:客戶端對服務端的驗證;通過對傳輸層傳輸的數據段進行加密確保消息的機密性。接下來通過一個例子,來描述連接HTTPS的過程

步驟1:客戶端向HTTPS站點發送協商請求,該請求中包含客戶端所能夠支持的加密算法列表。

步驟2:HTTPS站點從加密算法列表中選擇自己支持的並且安全級別最高的算法,連同綁定到該站點的數字證書(X.509證書)一並發個客戶端。

步驟3:客戶端接受到站點發回的數字證書後,通過驗證證書進而確定站點身份,在驗證成功的情況下,客戶端會生成一個隨機數,作為會話密鑰(Session Key),緩存在客戶端。客戶端會采用站點發回的加密算法,利用從證書中提取的公鑰進行加密。加密後的會話密鑰發送給站點後,站點使用自己的私鑰解密,至此客戶端和服務端具有一個只有彼此知曉的會話密鑰,所有請求消息和回復消息均用其加解密。(由於非對稱加密和數字簽名的知識相對基礎,就不詳細介紹了,如果需要,可以參見http://www.cnblogs.com/wanliwang01/p/aspnet_webapi_base01.html。

Transport安全模型的最大的優點就是高性能,雖然在消息交換前需要一個協商的過程,不過可以通過硬件加速。其不足是:依賴於集體的傳輸協議;只能提供點到點的安全,即客戶端直接連接到服務端的場景,如果需要增加消息路由的中間節點,也無法使用了;如果選擇該模型,意味著需要在傳輸層解決對客戶端的認證,但相應方案較少。

Message安全:直接將安全策略的目標對象轉移到消息本身,通過對消息進行簽名、加密實現消息安全傳輸。其不依賴與具體的協議,並可以提供端到端的安全,其是一種應用層的協議,配套方案很多。WCF的Message安全模式是圍繞4個標準的WS-*規範建立的,包括WS-Security、WS-Trust、WS-Secure Conversation和WS-Security Policy。

Mixed安全:由於前兩者都有著自己的優點和缺點,因此綜合考慮,存在如下的解決方案:消息的一致性、機密性和客戶端對服務端的認證通過Transport安全模式實現,而服務端對客戶端的認證采用Message安全模式。

認證和憑證:常見的認證方式包括用戶名密碼認證,例如Windows認證、Membership模塊、自定義認證等;NTLM,windows認證是實現單點登錄的理想方式,其通過賬號密碼得到一個憑證,在憑證超時前,可以用於任何應用;Kerberos,其比NTLM更加高效,安全,涉及客戶端、服務端和密鑰分發中心3方,整個過程包括獲得"認購權證"、通過"認購權證"購買"入場券"、憑票入場;數字證書認證,采用信任鏈的方式實現。

之前介紹的主要是安全概念,接下來則在WCF中,安全的具體實踐。以最簡單的BasicHttpBinding為例,其SecurityMode包括None、Transport、Message、TransportWithMessageCredential(等價Mixed)和TransportCredential。對於其中的Transport安全來說,其又包含6中客戶端憑證類型,None、Basic、Digest、Ntlm、Windows、Certificate。比如如下兩個基於basicHttpBinding配置,前者基於Message模式+X.509證書憑證,後者采用Mixed模式+用戶名/密碼憑證。其他的綁定類型雖然有不少差異,但原理一致,在這就不一一展開了。

技術分享 View Code

Tip:可以通過設置message的協商屬性來決定是否需要協商。

之前也曾提到,對於認證來說包括服務端認證和客戶端認證,涉及ServiceCredentials和ClientCredentials兩大類憑證。首先介紹服務認證,常見的服務端認證配置如下所示。

技術分享 View Code

通過MakeCert.exe工具創建一個證書

Makecert –n "CN=RootCA" –r –sv C:\Root.pvk C:\RootCA.cer
Makecert –n "CN=Xionger-PC" –ic C:\RootCA.cer –iv C:\RootCA.pvk –sr
LocalMachine –ss My –pe –sky exchange

在WCF中,服務身份通過ServiceEndpoint表示,在Windows認證下,通常使用SPN(Service Principal Name)和UPN(User Principal Name)兩種,如果采用X.509證書,可以通過X509CertificateEndpointIdentity和RsaEndpointIdentity表示。在服務引用或使用SvcUtil.exe導入元數據時,會將服務身份標識自動寫入配置中,如下所示。

技術分享 View Code

客戶端認證主要包含三種方式:Windows,其基於SSPI,這部分曾經在連接字符串中見到;用戶名,支持Windows、Membership、Custom三種,尤其是Membership的使用,請見接下來的代碼示例;X.509證書,在客戶端可以通過ChannelFactory.Credentials.ClientCertificate.SetCertificate方法設置,此外證書與Windows賬號映射可以通過<clientCertificate>節中<authentication mapClientCertificateToWindowsAccount="true">設置。

技術分享 View Code

消息保護,這部分保證消息的一致性和機密性,在WCF中,通過消息保護級別的概念來設置,包括None、Sign和EncryptAndSign三個級別,默認為EncryptAndSign級別,這部分的功能是通過之前章節介紹過的SecurityBindingElement的相關類來實現的。此外,為了減少多次認證的開銷,還有一個關於安全會話的概念,通過配置Binding->security->message中的establishSecurityContext屬性來實現,可以使多次消息交換使用同一個會話信道,這部分內容很多,還需要足夠的實踐。不過不管是什麽平臺和技術,基本的安全概念是相似的,在傳輸過程中,就是認證、數據一致性和機密性。

技術分享

在介紹完認證Authentication後,就進入了授權的模塊,當然還包含所有安全過程的審核工作。對於整個.NET體系來說,其用戶和角色等信息都是通過身份Identity和安全主體Principal兩個概念來表述的。前者包含用戶的基本令牌信息,可以是WindowsIdentity、GenericIdentity和X509三種類型,這兒值得一提的是GenericIdentity,如果采用自定義認證方式時,會選擇GenericIdentity這個類型。在服務安全開啟的情況下,服務端在經過認證後會創建一個上下文用於存儲基於當前服務調用相關的安全相關的信息,其關系如下表所示。

None

Windows

UserName

Certificate

windows

Membership

Custom

Default

Windows Account Mapping

Generic Identity

Windows Identity

Windows Identity

Generic Identity

Generic Identity

X509 Identity

Windows Identity

接下來,介紹主體的概念,簡單來說,主體是對標識的封裝,增加了所屬角色這一關聯屬性。在windows中,安全主體被保存在TLS線程本地變量上,可以通過Thread.CurrentPrincipal獲取。

常見授權方式包括Windows用戶組授權、ASP.NET Roles授權和自定義授權方式三種。Windows授權相對簡單,設置behavior.PrincipalPermissionMode= PrincipalPermissionMode.UseWindowsGroups即可,通過在方法上添加[PrincipalPermission(SecurityAction.Demand, Role="administrators")]控制windows下用戶的操作,這部分還涉及一個Impersonation身份模擬的概念,和win32有關比較復雜,就不細致介紹了。對於ASP.NET Roles提供程序來說,System.Web.Security.RoleProvider抽象類是其基礎,主要使用其子類SqlRoleProvider來處理,其配置如下所示。

技術分享 View Code

此外,還有自定義的授權方式,其設計AuthorizationPolicy、ServiceAuthorization、Claim和ClaimSet等多個類型,實現很復雜,需要時再查書實踐。

最後介紹安全審核部分,這部分其實和windows的事件管理器關系非常緊密,最簡單的配置就是在behavior節中,設置<serviceSecurityAudit auditLogLocation="Application" messageAuthenticationAuditLevel="SuccessOrFailure">。

雖然是這樣的瀏覽學習,不過也算是圓夢之旅,棒棒噠。

參考資料:

[1]蔣金楠. WCF全面解析[M]. 上海:電子工業出版社, 2012.

快速入門系列--WCF--07傳輸安全、授權與審核