I have a webservice and a Silverlight application.
I also have a crossdomain.xml and clientaccesspolicy.xml
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
here my cross domain policy
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy
SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="http://localhost/MHVWS/MachineHistoryWS.asmx" />
</cross-domain-policy>
My web service is being hosted in IIS.
With this configuration I still have this kind of error:
An error occurred while trying to make a request to URI 'http://localhost/MHVWS/MachineHistoryWS.asmx'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.
Please help
You only need one policy file. You dont require both.
Be sure one (or both) of those policy files exist in the same location (domain) as the webservice.
To debug and see what is going on, use a tool like Fiddler to verify the url path of the policy xml file the client is looking for.
Related
I'mm trying to proxy a service but somehow its not working the way other services did, what am I doing wrong?
This is the original service http://webservicesh.sc.gov.br/SEA/Materiais/Fardamento/WS_Materiais_v1.wsdl
What I did was:
<pattern:web-service-proxy name="BiometriaRH"
inboundAddress="http://LocalIP/services/BiometriaRH/WS_BiometriaRH_v1"
outboundAddress="http://webservicesh.sc.gov.br/SEA/RecursosHumanos/biometria/WS_BiometriaRH_v1.asmx"
wsdlFile="BiometriaRH.wsdl"/>
It does access the WSDL file but I can't load the service any place like soapUI or Eclipse...
Why do you configure wsdlFile="BiometriaRH.wsdl"? Did you manually customize it?
If not, and assuming a WSDL is served at this URL http://webservicesh.sc.gov.br/SEA/RecursosHumanos/biometria/WS_BiometriaRH_v1.asmx?wsdl , then you only need:
<pattern:web-service-proxy name="BiometriaRH"
inboundAddress="http://LocalIP/services/BiometriaRH/WS_BiometriaRH_v1"
outboundAddress="http://webservicesh.sc.gov.br/SEA/RecursosHumanos/biometria/WS_BiometriaRH_v1.asmx" />
I use Mule Server 3.3.0 CE, I generate this code:
<mule xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spring="http://www.springframework.org/schema/beans" xmlns:http="http://www.mulesoft.org/schema/mule/http"
xmlns:pattern="http://www.mulesoft.org/schema/mule/pattern"
xmlns:mule-ss="http://www.mulesoft.org/schema/mule/spring-security"
xmlns:ss="http://www.springframework.org/schema/security"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.3/mule.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/3.3/mule-http.xsd
http://www.mulesoft.org/schema/mule/pattern http://www.mulesoft.org/schema/mule/pattern/3.3/mule-pattern.xsd
http://www.mulesoft.org/schema/mule/spring-security
http://www.mulesoft.org/schema/mule/spring-security/3.3/mule-spring-security.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security-3.1.xsd">
<mule-ss:security-manager>
<mule-ss:delegate-security-provider
name="memory-dao" delegate-ref="authenticationManager" />
</mule-ss:security-manager>
<spring:beans>
<ss:authentication-manager alias="authenticationManager">
<ss:authentication-provider>
<ss:user-service id="userService">
<ss:user name="sepideh" password="16978413" authorities="ROLE_ADMIN" />
</ss:user-service>
</ss:authentication-provider>
</ss:authentication-manager>
</spring:beans>
<pattern:web-service-proxy name="myService"
wsdlLocation="http://ws.acme.com:6090/wsdl/weather-forecast">
<http:inbound-endpoint address="http://localhost:8090/service">
<mule-ss:http-security-filter realm="mule-realm" />
</http:inbound-endpoint>
<http:outbound-endpoint address="http://ws.acme.com:6090/weather-forecast" />
</pattern:web-service-proxy>
I run this project and I have below exception:
ERROR 2012-11-27 14:31:25,456 [[web_service].connector.http.mule.default.receiver.02] org.mule.exception.DefaultMessagingExceptionStrategy:
********************************************************************************
Message : Registered authentication is set to org.mule.module.spring.security.filters.http.HttpBasicAuthenticationFilter but there was no security context on the session. Authentication denied on endpoint http://localhost:8090/service. Message payload is of type: String
Code : MULE_ERROR-54999
--------------------------------------------------------------------------------
Exception stack is:
1. Registered authentication is set to org.mule.module.spring.security.filters.http.HttpBasicAuthenticationFilter but there was no security context on the session. Authentication denied on endpoint http://localhost:8090/service. Message payload is of type: String (org.mule.api.security.UnauthorisedException)
org.mule.transport.http.filters.HttpBasicAuthenticationFilter:160 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/security/UnauthorisedException.html)
--------------------------------------------------------------------------------
Root Exception stack trace:
org.mule.api.security.UnauthorisedException: Registered authentication is set to org.mule.module.spring.security.filters.http.HttpBasicAuthenticationFilter but there was no security context on the session. Authentication denied on endpoint http://localhost:8090/sevice. Message payload is of type: String
at org.mule.transport.http.filters.HttpBasicAuthenticationFilter.authenticateInbound(HttpBasicAuthenticationFilter.java:160)
at org.mule.security.AbstractEndpointSecurityFilter.authenticate(AbstractEndpointSecurityFilter.java:58)
at org.mule.security.AbstractAuthenticationFilter.doFilter(AbstractAuthenticationFilter.java:56)
+ 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything)
New wsdl address show me but I can't use this address for create web service.
All of solution link to this page, but I don't know how to change SoapUI to true value.
What should I change in my configuration?
Posting this might helps some one. People who migrating the HTTP connectors from Mule lower version to 3.6+ or 3.7( Because, I faced this error when upgrading). Please follow the link https://docs.mulesoft.com/mule-user-guide/v/3.6/configuring-the-spring-security-manager( We cannt configure mule-realm inside HTTP listener as like in version 3.3). When you try to hit it from SOAP UI, you will find the above error Registered authentication is set to org.mule.module.spring.security.filters.http.HttpBasicAuthenticationFilter but there was no security context on the session. It is not the problem with Mule config file.Need to change SOAPUI settings
2 ways to resolve this error:
Go to SOAPUI->File->Preference->HTTP settings-> enable the option Authenticate Preemptively
or
When setting the basic Auth In SOAPUI
Authorization->Basic -> Pre-emptive auth -> enable Authenticate Pre-emptively.
By default it will be 'Use global preference' which needs to be changed to Authenticate Pre-emptively
Thanks.
Seems related and the error you are getting is a red herring. Are you getting back a success response even if this is being logged?
http://www.mulesoft.org/jira/browse/MULE-5607
I have a web service with a client written in Java. The service works behind a firewall and if the java client wants to consume the service, then its request is blocked because the request contains links. So the request contains validator references like this:
...<S:Envelope xmlns:S="http://schemas.xmlsoap.org/wsdl/"...
Shall I fix it in the wsdl file? That is the only place which contains this link:
<definitions targetNamespace="http://mycompany.com/" name="RentalServiceService"
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:tns="http://mycompany.com/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
If I generate a client in .net from the wsdl file, then it does not put any link references into the request...
Thanks
Zoltan
Don't remove namespaces from the XML message. Configure your firewall instead!
Normally, SOAP is friendly with firewalls because it piggybacks on top of HTTP. If you remove the namespaces from the XML you might get it through the firewall but the web service that must make use of the message might fail to parse it because you removed the namespaces from it. XML namespaces are important because they correctly identify the domain to which each element inside the message belongs to.
Just as an observation, the <S:Envelope xmlns:S="http://schemas.xmlsoap.org/wsdl/"... is a copy paste error of some sort?... or maybe part of the problem?! The namespace for the SOAP envelope should be http://schemas.xmlsoap.org/soap/envelope/ for SOAP 1.1 or http://www.w3.org/2003/05/soap-envelope for SOAP 1.2.
That aside, if the SOAP message is correctly formatted, it should pass through the firewall. If it doesn't, then the solution is to configure the firewall properly and not mess with the SOAP message. Your network administrators should spend time understanding web services security and properly configure the firewall.
My suggestion would be to keep port 80 just for your users requests/responses from browsers and expose the service on a different port number with proper configurations. Maybe you could even set up a reverse proxy inside a DMZ to improve the web service security. With that, you won't expose your internal web service server directly to the Internet.
I am trying to program a VisualWebPart using Visual Studio 2010 which has to do a simple thing: invoke a web service (hosted in a remote server, NOT locally). When I execute within the Sharepoint site (version 2010, which I have published in my IIS) I get this error:
"The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'."
Pardon my ignorance, but the only difference here is the case of the Ntlm authentication scheme! I have been all over the web and found many related problems, but none of the solutions worked. Almost ALL solutions i found involve modifications in the webservice security configuration, this is not an option for me.
Looking for a solution, I created a sample windows form and invoked the web service from it: no problems whatsoever.
In order to be able to invoke the webservice correctly this is the necessary security configuration:
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" proxyCredentialType="Ntlm" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
I believe the problem is that I haven´t been able to properly set this security property to the web.config of my Sharepoint site, since I tried to put it in the security tag that appears in the web.config but still get the same error.
Any further information needed please ask, I am REALLY desperate, for days I have been with the SAME error.
In the end I was given permissions in their server: more precisely in the database which was the one that wouldn't let me create the web part in the server. Once this was done, the call to the webservice worked just fine, because they have the web.config correctly configured.
I have a C# .net webservice that I need to restrict access to. I already require my consumers to use a username and password to call the service. But, is there a way to restrict access to the actual asmx page and the WSDL? I would need to restrict access to the webservice by username/password and IP address. If a user did not have the correct credentials, I would not want them to know what webmethods exist in the webservice.
Can this be done though IIS? I know that I can restrict IP addresses through IIS, but can I also use usernames/passwords?
Is there any other way to do this outside of IIS, maybe using C#.net?
Well, since it's ASMX you have the entire ASP.NET runtime stack at your disposal.
Step #1 - managing the resource through .config
Apply a <location> tag for the resources you want secured. Assuming it's a single ASMX file you can simply do the following in your web.config:
<location path="MyWebService.asmx">
<system.web>
<!-- resource specific options will go here -->
</system.web>
</location>
Step #2 - authenticating your users
You need to decide how you're actually going to authenticate users. There are several ways to do this and several authentication standards you could leverage. You need to pick the approach that's the right fit for you.
If you're on an intranet and are using Windows authentication I would highly suggest leveraging that because it's truly the simplest option to get setup. However, if your services are being accessed over the internet then Windows authenticatio is not really an option and you need to choose from a web standard. The simplest of those is Basic Authentication, but you should only use this over SSL since the username/password are not encrypted (only base64 encoded). The next step up from that is Digest authentication which doesn't require SSL because the username/password are sent using an MD5 hash. For the ultimate you can go with SSL v3 where you issue a specific client certificate to each user of your API.
Now, which option you select for security dictates what else needs to be done. If you choose Windows security, it's as easy as adding the following element to the <system.web> element we started with in Step #1:
<authentication mode="Windows" />
The remainder of the security protocols are going to require a little more work. ASP.NET doesn't provide intrinsic support for Basic, Digest or SSL v3. Technically you can leverage IIS to do this type of authentication for you, but it's always going to map to a Windows user. If that's an option for you, then simply leave the <authentication mode="Windows" /> element and configure IIS accordingly. If, however, that is not an option, either because you simply have no control over IIS/ActiveDirectory or you need to authenticate against a custom user database, then that means that you need to hook up a custom HttpModule to provide support for these security protocols.
Step #3 - securing the resource
The simplest approach to securing the resource is to basically say: "don't let anyone who hasn't successfully authenticated in some way into this resource". This is done using the following authorization configuration:
<authorization>
<deny users="?" />
</authorization>
If you wanted to only allow certain users you could change to do the following instead:
<authorization>
<deny users="*" />
<allow users="jdoe, msmith" />
</authorization>
Another approach is to define roles (groups) and simply lock the resource down to a special role which you put the users who you want to access the resource into.
<authorization>
<deny users="*" />
<allow roles="My Service Users" />
</authorization>
This maps well to Windows authentication because you can just setup a Windows group and let your MIS team manage which users are in that group using ActiveDirectory. However, the feature also works just fine for non-Windows authentication assuming the security implementation you've used exposes roles via its IPrincipal implementation.
I don't know how practical this is for you, but you could consider upgrading to WCF. WCF is fully backward compatible with ASMX web services, and lets you control whether or not the WSDL is exposed by defining a MEX (metadata exchange) endpoint. No MEX endpoint, no WSDL.
You can stop WSDL being shown by removing the Documentation protocol from the element in Machine.config
Update:
Web Services authentication - best practices?
If your users have usernames/passwords you can use HTTP basic authentication via HTTPS.
You can also implement it in a slightly differnt way. The first call to your web service should be the authentication method. Client authenticates and receives an authentication token. This token should be presented to all other methods exposed by your web service.
Two options: Create an entirely different site on a different port with locked down permissions. This has the advantage of providing some amount of "security through obscurity" (half joking...) Or you can add a new Application under your site(same port, different path), on a different app pool and assign permissions that way.
In either case, your web service isn't going to be able to talk with the various ASP.NET "things" like the application object (well it will, but it won't be the same one). Deployment is only slightly harder: deploy the same binaries, but only include the one web service file.
You can authenticate using an HttpModule.
SSL + BasicAuthentication should yield the best interop with other tool chains.
In the HttpModule, you have access to the request and can deny unauthenticated users access to just .asmx requests. And even then you might let them access the WSDL.
Add <add path="*.asmx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" /> to the <httpHandlers> section of the web.config file