I have a scenario where I want to consume a Webservice from a different server within our corporate network using JQuery. My origin application is an ASP.NET Website running on IIS 7.5, the Webservice is running on an SAP Netweaver Gateway, so no Chance to allow my IIS host there or to use JSONP.
The problem is that I run into the CORS issue, so I installed ARR on my IIS machine and tried to do a rewrite url and use my IIS to consume the remote Webservice. But the problem is, that the target Webservice requires Certificate authentication and it seems that this is not supported by ARR. Am I correct?
Any help is appreciated,
Oliver
I have had a similar issue, in my first try I had both my application and ARR running on the same box and this was causing the Application's Authentication module to start first before ARR and was messing up the things, I found success when I had both of them run on different boxes. Below link helped me
http://blogs.msdn.com/b/asiatech/archive/2014/01/28/configuring-arr-with-client-certificate.aspx
Related
I have a working WCF Service, that does what it should do, hosted by an IIS.
Now in another environment, this service shall be used as ever, but IIS should additionally require a client certificate for allowing to access.
So I generated some certificates, used iisClientCertificateMappingAuthentication to configure them and map them to users. So I can control which users can access the website and I see to what user the certificates are mapped in the FailedReqLogFiles.
Then I added a sub directory, put the WCF application in there, converted to an application with an apppool and ther the pain began.
The WCF Service is determined to demand that 'Anonymous authentication' must be activated. When I activate anonymous authenticaiton, the service can be invoked, but from then on, it doesn't matter which certificate is used for authentication.
I googled tons of articles and tried lots of configurations, but didn't success so far. I must admit, I'm not very familiar with WCF, this always drove me crazy. I do simply not understand why an application deals with the way the Webserver handles security (it's smiliar to adding SSL, when WCF is not configured properly, IIS shows 404, that's also one thing i do not understand, why the WCF is interfering with the way IIS exposes content to the world...).
Hope there's someone who could give advice, thank you very much in advance.
Regards, Chris
You could try below setting in iis to resolve the issue:
1)Open iis manager, select your site.
2)select the SSL setting from the middle pane.
3)in SSL setting check require SSL, client certificate select accept radio button.
4)click on apply and restart iis.
You could refer the below link for how to set iisclientcertificate authentication with WCF:
WCF Service Using Client Certificates Requires Anonymous Access in IIS and Therefore Doesn't Actually Work?
How do I implement Client Certificate authentication the right way?
https://learn.microsoft.com/en-us/iis/configuration/system.webServer/security/authentication/iisClientCertificateMappingAuthentication/
In Server1 - (IIS hosted, Self Signed Certificate)
I hosted the IdentityServer3 named myDevIds3.com , the Url is exposed to internet, with SSL.
I hosted the ASP.Net MVC Client, which uses ids3 for login, works fine.
I hosted the Web API, which is called by the MVC Client, uses ids3 (in the same server), works fine.
In Development Server / Box.
I hosted MVC client (X), which uses client side js famework (https://github.com/IdentityModel/oidc-client-js) to connect to Server1 hosted ids3 (myDevIds3.com), works fine.
I hosted an Web API, which is called by MVC Client (X), while API uses myDevIds3.com for authorisation. [HERE is the problem]
When I try to access this Web API, I am getting an error in the Startup.cs - The remote certificate is invalid according to the validation procedure.
BUT I tried in other way.
I hosted another IdentityServer3, the MVC Client, the API also in development box, mapped to local identityserver3 with MVC client & apit, looks everything seems to be working with out any issue. If I put everything together in one box, everything seems to be working.
What is wrong in accessing the remote machine IdentityServer3 in Web API which is hosted in local development Box ? Why I am able to access from the browser, but not from development box IIS ?
Appreciate your time and inputs.
Because your ssl cert is probably home made and not trusted. Guessing Chrome also gives you warning about this (?).
CAUTION: This solution is not recommended for production, but this can be used for non production environments, where your data is not critical.
Add below code in Startup.cs (Web API)
ServicePointManager
.ServerCertificateValidationCallback +=
(sender, cert, chain, sslPolicyErrors) => true;
This can be refered in below link aswell.
C# Ignore certificate errors?
I found this solution helpful, since I want to have identityserver3 DEV hosted centralised and multiple developers need to access it. Hope it might help someone.
I followed the tutorial deploy and run Service Stack application on Ubuntu Linux and I got my API quickly up and running. So far it's all plain-text though. I'd like to secure the API with SSL, especially the service receiving username and password, but maybe everything.
I'm using the regular CredentialsAuthProvider together with JwtAuthProvider at the moment, if it's relevant. Using a 3rd party OAuth2/OpenID Connect would solve the login problem, but not securing the remaining contents.
Also wonder how to selectively choose which services require SSL.
The stack is: mono, nginx and HyperFastCGI (and C# ServiceStack)
You'll want to configure SSL on nginx, i.e. your external-facing Web Server. What ASP.NET Web framework you're using is irrelevant as SSL will be terminated at nginx and any downstream Web Applications will still be receiving plain-text requests.
Here is my scenario:
I have a proxy that actually has the SSL Cert installed and this sits in front of a load balanced web farm. Each IIS server does not have SSL so I can't use transport security via wsHttp binding. I have not investigated basicHttp because we want to provide SOAP 1.2 going forward w/ this solution. In addition to this, my network team won't allow any use of certs to encrypt at the message level. (this alone would solve my dilemma i'm sure)
My security group has a requirement that we use Forms Authentication (membership provider).
The final solution must allow SSL via the front proxy, yet some type of WCF binding to keep complexity encapsulated in a config file.
I was working with a custom binding that allowed for username/password sent via clear text, but when I try to connect via https i get the usual "http expected" uri error.
How can I use SSL via the proxy to connect securely from client app to web service, but not have SSL installed on IIS and leverage the WCF stack + forms authentication?
I'm not new to WCF, but this very custom setup seems to have me unsure if the requirements allow for any type "easy" solution.
Thank you in advance!
EDIT: I did finally get this working and decided to write a short blog post with complete source code required to write the custom binding.
I think this is similar to a problem many have had when wanting to provide WCF services over SSL when the actual service in IIS is behind an SSL-offloading device. In which case, the following two pages should help you out:
http://blog.hackedbrain.com/archive/2006/09/26/5281.aspx
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/87a254c8-e9d1-4d4c-8f62-54eae497423f/
Basically you need to lie to WCF and say that the service is secure, even though the traffic will be conducted over HTTP (between the service and the proxy).
Can anyone give a clear explanation of the difference between using
clientCredentialType=Windows, and
clientCredentialType=Ntlm
in a server-side Web.config when hosting a WCF service?
I have a SOAP 1.1 (basicHttpBinding) service for interop with existing clients. It uses ASP.NET roles so needs clients to be authenticated.
When I am using the VS2005 (Cassini) server to host the service, I have to specify ClientCredentialType=Ntlm as above, and check the Ntlm authentication box in the project properties in VS2005. ClientCredentialType=Windows doesn't work - clients get a:
401 Unauthorized error
However when I'm running under IIS, it's the other way around: ClientCredentialType=Windows works, and ClientCredentialType=Ntlm fails.
Can anyone explain this, and preferably suggest a way I can have the same web.config file to run the service in Cassini and IIS?
Update
I have .NET 3.5 SP1 on my dev machine, which is XP SP2 running in a domain. Cassini therefore runs under a domain account, and IIS 5.1 under a local account.
I wonder if it could be related to the breaking change in .NET 3.5SP1 described in these articles.
http://www.aspnetpro.com/newsletterarticle/2008/12/asp200812ab_l/asp200812ab_l.asp
http://msmvps.com/blogs/alvin/archive/2008/11/14/net-3-5-sp1-breaking-change-to-wcf.aspx
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=354236
The situation sounds similar as clientCredentialType=Windows fails when the server is running under a domain account (which is my situation with Cassini - running as my normal domain user account), and works when running under a local account (which is my situation with IIS).
The problem is that the suggested fixes require changes to a WCF client configuration file - but in my case I'm using SOAP 1.1 (basicHttpBinding) with non-WCF clients.
clientCredentialType=Windows uses the built in Windows authentication which can be through Active Directory and NTLM.
Obviously the NTLM type will only use NTLM for authentication.
I'm sure you've seen it already, but here is a link to WCF security:
http://msdn2.microsoft.com/en-us/library/ms734769.aspx
Some more details on your setup would help. Are the IIS and Cassini servers running on the same box? If not do you have the same accounts setup on each box? IIS6 by default supports NTLM, so you shouldn't have a problem getting it to work.