2011-11-12 50 views
1

背景(一丁點長)如何讓WCF和Java客戶端正常工作。專家需要幫助

幾年前,我寫了一個客戶被配置爲使用安全模式=「運輸」與clientCredentialType =「證書的basicHttpBinding的WCF服務「,即客戶使用(客戶)證書對自己進行身份驗證。該服務使用自定義的AuthorizationManager來檢查傳入證書的指紋是否存在於有效證書指紋的預定義列表中。如果傳入證書被認爲是有效的,則允許該操作繼續(如果不是,則拋出異常)。

該服務已完美工作大約四年,每個人都很開心。但是,隨着需求的變化經常發生,最近我的客戶已經接觸到希望將他們的應用程序連接到我的客戶服務的開發人員。唯一的問題是這些開發人員正在使用某些Java變體作爲他們的首選平臺,現在我們正面臨一些嚴重的問題。長話短說,沒有人設法讓他們的Java實現(例如Metro,Axis2)在當前配置的服務中工作。

上週我們嘗試通過使用消息clientCeredentialType =「UserName」的安全模式=「TransportWithMessageCredential」將綁定更改爲wsHttpBinding,以使用Java編寫的客戶端(Metro,JAX-WS)工作。我還在配置文件的service credentials元素中添加了一個自定義的UserNamePassWordValidatorType。

然後我註釋掉了自定義的AuthorizationManager,因爲沒有來自客戶端的證書。

Lo'看到了,這一次我們得到了SoapUI和Java客戶端的正確服務。

(順便說一句,我們的服務是自託管在Windows服務)

高興,因爲可以,我們決定用兩個綁定,現有的basicHttpBinding的一個已經工作無故障時間長配置服務,和新測試的wsHttpBinding。所以我們會有這樣的東西:

<services> 
    <service name="SuperDuperService" behaviorConfiguration="superDuperBehaviour"> 
     <endpoint binding="basicHttpBinding" contract="ISuperDuperService" bindingConfiguration="SecureTransport"/> 
     <endpoint binding="wsHttpBinding" address="stws" contract="ISuperDuperService" bindingConfiguration="SecureTransportAndSoap"/> 
     <endpoint binding="mexHttpsBinding" address="mex" contract="IMetadataExchange" /> 
     <host> 
      <baseAddresses> 
       <add baseAddress="https://<url + port>/SuperDuperService"/> 
      </baseAddresses> 
     </host> 
    </service> 
</services> 
<bindings> 
    <basicHttpBinding> 
     <binding name="SecureTransport" maxBufferSize="2065536" maxBufferPoolSize="524288" maxReceivedMessageSize="2065536"> 
      <security mode="Transport"> 
       <transport clientCredentialType="Certificate"/> 
      </security> 
      <readerQuotas maxDepth="32" maxStringContentLength="6553600" maxArrayLength="2065536" 
       maxBytesPerRead="4096" maxNameTableCharCount="16384" /> 
     </binding> 
    </basicHttpBinding> 
    <wsHttpBinding> 
     <binding name="SecureTransportAndSoap"> 
      <security mode="TransportWithMessageCredential"> 
       <message clientCredentialType="UserName"/> 
      </security> 
     </binding> 
    </wsHttpBinding> 
</bindings> 
<behaviors> 
    <serviceBehaviors> 
     <behavior name="superDuperBehaviour"> 
      <serviceCredentials> 
       <!-- The following element specifies the certificate use by this service for HTTPS (SSL) based transport security --> 
       <serviceCertificate findValue="<some identifier>" 
         storeLocation="LocalMachine" 
         storeName="My" 
         x509FindType="FindBySubjectName" /> 
       <userNameAuthentication userNamePasswordValidationMode ="Custom" customUserNamePasswordValidatorType 

="SupportClasses.CustomUserNameValidator,SupportClasses"/> 
      </serviceCredentials> 
      <!-- The following element specifies how we're authorizing based on the client certificates received --> 
      <serviceAuthorization serviceAuthorizationManagerType="SupportClasses.AuthorizationManager, SupportClasses"/> 
      <serviceMetadata httpsGetEnabled="true"/> 
      <serviceDebug includeExceptionDetailInFaults="false"/> 
     </behavior> 
    </serviceBehaviors> 
</behaviors> 

那麼你可能會問的問題在哪裏?那麼看到<serviceBehavior>元素?正如你可能知道這個元素全局適用於這個服務,這意味着在運行時CustomUserNameValidator和AuthorizationManager都會被調用。後者會抱怨當客戶使用wsHttpBinding調用服務時,不存在證書!

唉!

替代解決方案

到目前爲止,這些都是替代解決方案我想出了:

方案1)創建另一個Windows服務在不同的URL託管我們的WCF服務。那麼這兩個服務將有一個單獨的配置。

方案2)創建同一個Windows服務託管兩個服務實現和每個暴露他們倆中的元素與自己的約束力和serviceBehaviour

替代3)圖,如果它是在所有可能的保持當前配置,並使CustomUserNameValidator和AuthorizationManager和平共存

對不起,對於這篇較長的文章,但我需要在爲我的問題提供背景時做到徹底。

問題1)有沒有人得到WCF與Java客戶端使用非平凡配置工作?

問題2)有沒有人有關於如何解決替代3的建議? (如果可能的話)

問題3)你會推薦哪一種,如果有的話?

問題4)有沒有其他的選擇你知道我沒有想到?

爲了記錄,我查看了WCF互操作性工具,但我無法真正瞭解它如何幫助我們。如果有人讀到這個使用互操作性「嚮導」的好結果,請讓我知道。

在此先感謝。

--norgie

回答

0

我會通過添加//服務第二元件啓動和配置一個新的@bindingConfiguration屬性和不同的屬性@address。我認爲選擇1,2或3會更簡單;或者也許它是替代方案3,我不知道。

存在Web服務以提供語言,供應商,平臺和供應商中立的互操作。 WCF和Java每天都在真實世界的解決方案中進行互操作。

你看過這個系列WCF and Java interoperation?另外,聽起來你會從使用一些診斷工具中獲益,這些工具可以讓你看到.NET/WCF客戶端消息和Java客戶端消息之間的不同。使用Fiddler或其他嗅探器實用程序來查看電線上的消息。打開WCF跟蹤以查看WCF收到該消息後會執行的操作。

+0

感謝您的回覆。我會讀你提供的文章系列。當涉及到診斷時,我們使用WCF跟蹤確認客戶端證書丟失。我們設法使用用戶名/密碼認證工作,但客戶端證書問題仍然困擾着我們。我最終編寫了一個本地運行的橋接服務,處理與服務的安全對話。然後java解決方案使用普通的基本http綁定與橋接服務進行通信。 – norgie