 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / February 2005URI in Policy EndPoint Case Sensitive?
A client and I worked for 2 days on a WSE issue where the URI specified in the policy was all lowercase. The final soap exception being dealt with before we got it running was that the current policy did not match the original policy. The client was making the call to the secured service with a camel cased URI, and this was apparently causing an issue. The client and server were using 2 way encryption and signing as well as a secure channel. After they made the query string all lower case, to match what was in the policy cache config, it all worked. If you actually used the MSF Design Process, you could classify this issue as being undocumented, with low visibility and having a very severe impact. Is this facet of the policy documented in the help somewhere? Why would case of the URI have anything to do with anything with regards to signed and encryped data? Hi, Could you please provide a little detail on what sort of URI's that you are dealing with? Could you perhaps give an example of the URI in the policy file, versus the URI that you are actually sending the request to? Thanks, Sidd [MSFT] > A client and I worked for 2 days on a WSE issue where the URI specified in > the policy was all lowercase. The final soap exception being dealt with [quoted text clipped - 14 lines] > case of the URI have anything to do with anything with regards to signed and > encryped data? Hello DevilDog74, Yes it is case sensitive and it certainly needs to be addressed IMO HTH Regards, Dilip Krishnan MCAD, MCSD.net dkrishnan at geniant dot com http://www.geniant.com > A client and I worked for 2 days on a WSE issue where the URI > specified in the policy was all lowercase. The final soap exception [quoted text clipped - 15 lines] > would case of the URI have anything to do with anything with regards > to signed and encryped data? Hi Dilip, I do not believe the endpoint uri specified in the policy file is case sensitive. Could you please give me an example of this as this needs to be investigated ASAP. In you response, if you could let me know if you are using ASMX, or soap.tcp, that would be very helpful as well. Thanks Sidd [MSFT]. > Hello DevilDog74, > Yes it is case sensitive and it certainly needs to be addressed IMO [quoted text clipped - 24 lines] > > would case of the URI have anything to do with anything with regards > > to signed and encryped data? > Hi Dilip, > [quoted text clipped - 37 lines] > > > would case of the URI have anything to do with anything with regards > > > to signed and encryped data? The URIs provided in this scenario are not real, but demonstrate what I am talking about, so please bear with me. We have a service hosted in IIS called myservice.asmx. The server is configured using the policy tool, it uses x509 and the wsdl can be found at http://www.somedomain.com/webservices/myservice.asmx. The service is set up to use a secure channel, plus 2 way signing and encryption. Using the VS.NET 2003 IDE, the client obtains a direct web reference to the wsdl. In the Add Web Reference tool for the IDE, the developer enters http://www.SomeDomain.com/WebServices/MyService.asmx, the wsdl is retreived and the reference is created in the IDE, along with the proxy, etc etc. The url entered into the ide is camel cased. The developer then configures the cleint to use WSE2, using the WSE IDE tool. They configure their policy using the WSE policy addin. In their policy, when they add their endpoint name, they dont use the <DefaultEndpoint> they enter http://www.somedomain.com/webservices/myservice.asmx and configure their policy to be a client application, using s channel, with 2 way x509 signing and encryption. The developer builds and runs the client application and should receive a nice undocumented WSE policy verification error stating something along the lines that the current endpoint doesnt match the policy that it was mapped to. > Hi Dilip, > [quoted text clipped - 37 lines] > > > would case of the URI have anything to do with anything with regards > > > to signed and encryped data? Hi, I don't seem to be able to repro this. I have tried all sorts of casing possible. Are you using WSE 2 SP2, or WSE 2 RTM? I would really appreciate it if you could send me a small repro, or even if I could send you a repro and let me know what I am doing wrong. Your input on this is very much appreciated. Thanks, Sidd [MSFT] > The URIs provided in this scenario are not real, but demonstrate what I am > talking about, so please bear with me. [quoted text clipped - 63 lines] > > > > would case of the URI have anything to do with anything with regards > > > > to signed and encryped data? I recalled a similar post a few months ago which [Lucien] and [Hervey] replied that: Quote: URI's are treated case sensitive as defined in specifications/RFC (except for the host name part). Arguably this is a bug in IIS and this is 'fixed' in WSE. You could use default endpoint with action string URI's instead (if that would fit into your scenario). Quote: This is a known bug that is fixed and will be in the next release. The action value is to be treated as is (case sensitive) per WS-Addressing spec. I would though recommend against using upper case in host name part.  SignatureThank you. Regards, William T (Softwaremaker) http://www.softwaremaker.net/blog ========================================= > Hi, > [quoted text clipped - 88 lines] > > > > > would case of the URI have anything to do with anything with regards > > > > > to signed and encryped data? Did you try making the URI dynamic and specifying the uri in the web .config instead of the proxy? In any case, both the client and the server are on WSE2SP2. using default endpoint in the policy is not feasablee because why shoud we need to maintain 3 policy files that essentially have the same information in them except for where the service lives? The reason we use the named endpoint is because in our real scenario, I have dev1.mydomain.com, qc1.somedomain.com, and prodution1.somedomain.com, all of which have the same policy requirements. > I recalled a similar post a few months ago which [Lucien] and [Hervey] > replied that: [quoted text clipped - 111 lines] > regards > > > > > > to signed and encryped data? So, I was able to repro this. In the ide change the URL Behavior from static to dynamic. This action modifies the web.config file and modifies the constructor of the proxy. In my poliy the endpoint is all lower case. In my web.config, for the first test using SoftwareMakers post, I made the first letter of the host name uppercase. This test returned the proper results. In the second test, I made the first letter of evey word not in the host name uppercase and re-ran the test. I received the exception listed below, so it is cse sensitive, and my point is that doesnt seem to be documented and costs my organization a lot of time and money and now we have the client asking if we should event use WSE over something that is so silly compared to what the end result is. From the clients perspective, they cannot see the fact that their data is signed and encrypted and communicating over a secure channel. All the client sees is that their web services arent working and they are out 2 days of development. System.Web.Services.Protocols.SoapHeaderException: Microsoft.Web.Services2.Policy.PolicyVerificationException: WSE402: The message does not conform to the policy it was mapped to. at Microsoft.Web.Services2.Policy.SimplePolicyVerifier.VerifyMessageWithExpression(PolicyExpression expression, SoapEnvelope message, EndpointReference endpoint, String action, Uri requestEndpoint) at Microsoft.Web.Services2.Policy.SimplePolicyVerifier.Verify(SoapEnvelope message) at Microsoft.Web.Services2.Policy.PolicyVerificationInputFilter.ProcessMessage(SoapEnvelope envelope) at Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope envelope) at Microsoft.Web.Services2.WebServicesExtension.BeforeDeserializeServer(SoapServerMessage message) at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at WebServiceWse.myCourseList(String strOPEID) in c:\elogic\wseclient\elogic.dev.proxy\web references\com.elogiclearning.dev.usafunds\reference.cs:line 78 at eLogicWebClient.WebForm1.cmdGetData_Click(Object sender, EventArgs e) in c:\elogic\wseclient\elogic.webclient\default.aspx.cs:line 66 > Did you try making the URI dynamic and specifying the uri in the web .config > instead of the proxy? [quoted text clipped - 124 lines] > > regards > > > > > > > to signed and encryped data? Softwaremake, I actually gave you misinformation. The policy requirements are not the same on all 3 services. In the production1.somedomain.com, the private key is a private key provided by a "Real" thawte ssl certficate, where as with the dev1 and qc1 policy, the certificate being used is issued by our development certificate server. > So, I was able to repro this. In the ide change the URL Behavior from static > to dynamic. This action modifies the web.config file and modifies the [quoted text clipped - 167 lines] > > > regards > > > > > > > > to signed and encryped data? Hi DevilDog74, You are getting the WSE402 error because the client policy is not getting enforced, thereby sending out the message in plain, and hence when the message gets to the service, it does not conform to the security requirements specified in the server's policy file. You can verify this by turning on trace at the client side to see if the message is really getting signed/encrypted (or whatever it is that would make it conform to the server's policy) If your endpoint uri's are the same and are lower case in BOTH your client policy as well as your servers policy, then the exception you display below doesn't fit well with your description because if the policy engine indeed did a case sensitive match of the URI, then you would get a different error message, something more along the lines of "No policy could be found for this message", and not a "Message does not conform to the policy". I have tried to modify the X509Signing policy sample that comes with WSE2 SP2, and this is what I have currently: proxy.Url = "http://hostname/X509SignPolicyService/X509SigningService.asmx" client endpoint uri=http://hostname/x509signpolicyservice/x509signpolicyservice.asmx server endpoint uri=http://hostname/x509signpolicyservice/x509signpolicyservice.asmx (same as the client's endpoint uri) and I cannot repro it. The policy engine in WSE does not do a normal URI comparison, otherwise the URI's listed above (the proxy.Url and the client endpoint uri) would not be equal. If you could let me know of something that I am missing that would be great. I know this is a pain when it comes to uri comparison's, and any details you can provide me, possibly with a repro using a quickstart (where I can just change the hostname) would be great. This will help me address the issue faster into the product. Thanks, Sidd [MSFT] > So, I was able to repro this. In the ide change the URL Behavior from static > to dynamic. This action modifies the web.config file and modifies the [quoted text clipped - 19 lines] > Microsoft.Web.Services2.Policy.PolicyVerificationException: WSE402: The > message does not conform to the policy it was mapped to. at Microsoft.Web.Services2.Policy.SimplePolicyVerifier.VerifyMessageWithExpress ion(PolicyExpression > expression, SoapEnvelope message, EndpointReference endpoint, String action, > Uri requestEndpoint) at > Microsoft.Web.Services2.Policy.SimplePolicyVerifier.Verify(SoapEnvelope > message) at Microsoft.Web.Services2.Policy.PolicyVerificationInputFilter.ProcessMessage( SoapEnvelope > envelope) at > Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope envelope) > at Microsoft.Web.Services2.WebServicesExtension.BeforeDeserializeServer(SoapSer verMessage > message) at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClient Message > message, WebResponse response, Stream responseStream, Boolean asyncCall) at > System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String [quoted text clipped - 132 lines] > > > regards > > > > > > > > to signed and encryped data? Hello Sidd, I really appreciate your time on this. I have a sample all boxed up and ready to go. You can contact me via email at cbertolasio AT gmail dot com AT = @, dot = . Once I get your email, I will forward you the zipped sample. > Hi DevilDog74, > [quoted text clipped - 267 lines] > > > > regards > > > > > > > > > to signed and encryped data? After working on this issue a bit longer we determined that the url is case sensitive on a WSE2SP2 machine if there is a binding redirect in the GAC that points all calls to the WSE2SP1 assembly OR the client making the call is WSE2SP1. With a binding redirect, the client is executing WSE2SP1 code, even though WSE2SP2 is installed. I was doing a Binding Redirect to mimic my clients scenario, as my client had WSE2SP1 installed and all of my development workstions and host servers were WSE2SP2 except for 1. In all scenarios where the client calling the service is WSE2SP2, we found that the URL passed to the proxy IS NOT CASE SENSITIVE. > Hello Sidd, I really appreciate your time on this. I have a sample all boxed > up and ready to go. You can contact me via email at cbertolasio AT gmail dot [quoted text clipped - 275 lines] > > > > > regards > > > > > > > > > > to signed and encryped data? Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.