Silverlight 4 & WCF: Windows Authentication keeps popping up - wcf

we have devloped a SL4 application with a WCF service. The SL application and the service are hosted in IIS 7 with windows authentication enabled and everything else disabled.
In the wwroot i have this client access policy file:
<?xml version="1.0" encoding="utf-8"?>
<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>
and this crossdomain file:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
the service config of the silverlight xap looks like this in the client section:
<binding name="SilverlightEndpoint" maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647">
<security mode="TransportCredentialOnly" />
</binding>
....
<client>
<endpoint address="http://app.domain.intern/MyService/MyService.svc"
binding="basicHttpBinding" bindingConfiguration="SilverlightEndpoint"
contract="[interface]" name="SilverlightEndpoint" />
</client>
Now when I open my application in internet explorer it prompts me to enter my windows login credentials, after that everything works fine. In my dev environment integrated authentication works without a hitch, i dont have to enter my credentials before accessing my application. In fact, integrated authentication worked in production as well when I had the following endpoint address in the client config: "http://[servername]/MyService/MyService.svc".
Does anyone know how I can get my integrated authentication back?

Finally, I figured this out.
You really dont have to change anything in the client config. I just kept the endpoint address "http://[servername]/MyService/MyService.svc" and ignored the DNS alias.
The problem was with the browser security settings. In Internet Explorer 8, i had to manually add the dns alias to the trusted sites in the local INTRANET zone (that's important). Then everything worked fine, whether I accessed the app with the server name or the dns alias and the authentication pop up went away.

Related

How do I enable IIS Express to serve external requests

This is a re-post of an earlier issue. After a long hiatus with respect to this topic I am back to it again.
I need to make my local dev IIS Express instance available to colleagues for testing purposes. After much reading and many blind alleys, I managed to get a little bit further than I did when this was originally posted, in that I have managed to get VS 2022 to recognise the entries from the applicationHost.config that are needed, unfortunately when I debug the website, IIS Express (or rather MS Edge) responds with:
Hmmm... Cant reach this page
machinename.euro.org.local refused to connect
Note the URL is obfuscated for security reasons.
The applicationHost.config file contains the following entries:
...
<site name="appName" id="1">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="C:\appPath\appName" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:8080:machinename.euro.org.local" />
<binding protocol="https" bindingInformation="*:44379:machinename.euro.org.local" />
</bindings>
</site>
VS confirms that the virtual directory has been successfully created.
I have made the necessary additions to HTTP.SYS:
netsh http add urlacl url=http://machinename.euro.org.local:8080/ user=everyone
and to my firewall settings:
netsh firewall add portopening TCP 8080 IISExpressWeb enable ALL
Where am I going wrong?

allowDoubleEscaping on .net core 2.0

I am using asp.net identity and GenerateEmailConfirmationTokenAsync gives me a token for email confirmation. I cannot use this code in confirmation url, because it gets an error :
The request filtering module is configured to deny a request that contains a double escape sequence.
The solution for that issue was to allowDoubleEscaping in web.config, but how can I do it in appsettings.json? I should write this code somehow in appsettings, or in Startup.cs:
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true"/>
</security>
</system.webServer>
It's still an IIS setting if you're running in IIS.
Create a web.Release.config file (you don't need a web.config file in your actual project) with the following:
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<location>
<system.webServer>
<security xdt:Transform="InsertIfMissing">
<requestFiltering allowDoubleEscaping="true" />
</security>
</system.webServer>
</location>
</configuration>
When you publish a release build this will get added. Very important to include the part InsertIfMissing or it will be ignored.
You DON'T need a third party package such as this. 7
See also https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/transform-webconfig?view=aspnetcore-3.1

Web API Windows Authentication hosting in IIS

I am working on WEB API Windows Authentication. I have added below config in web.config
Getting this issue:
This configuration section cannot be used at this path.
This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false"
Please help me on this. Please provide steps how to achieve window authentication in web api
The reason why this error encounters is probably because of the
settings to enable windowsauthentication in IIS via the
web.config file. To resolve this you have to adjust the applicationhost.config file of the IIS server. You need to tell IIS that his own configuration may be overwritten:
For IIS Express follow these instructions
For IIS Server follow 'section applicationhost.config'
Below steps (simple scenario) to allow windows authentication
Assure the webapi project is using windows authentication.
<system.web>
<authentication mode="Windows"></authentication>
</system.web>
Set IIS to windowsAuthenthication and nothing else by configuring the config file
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" />
<anonymousAuthentication enabled="false" />
<basicAuthentication enabled="false"/>
</authentication>
</security>
</system.webServer>
Adjust the applicationhost.config of IIS like described above.

Cannot get SSL to work on Azure instance

I've been tearing my hear out trying to figure out why SSL works in one of my Azure projects but not in another.
When I navigate to my site, say https://foo.com, I can't even connect to the site. Browsers can't connect at all and curl says "couldn't connect to host". However, if I go to my cloudapp.net URL (e.g. https://foo.cloudapp.net), it can connect but browsers will complain and say my cert is for *.foo.com. Note: I am able to connect to http://foo.com without any trouble.
Here's my code with certain values obfuscated.
ServiceDefinition.csdef:
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="MyApp" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="www" vmsize="Small">
<Sites>
<Site name="Web">
<VirtualApplication name="r" physicalDirectory="../Foo/Bar" />
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
<Binding name="Endpoint2" endpointName="Endpoint2" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" />
<InputEndpoint name="Endpoint2" protocol="https" port="443" certificate="STAR.foo.com" />
</Endpoints>
<Imports>
<Import moduleName="Diagnostics" />
</Imports>
<Certificates>
<Certificate name="STAR.foo.com" storeLocation="LocalMachine" storeName="My" />
</Certificates>
</WebRole>
</ServiceDefinition>
my cert is uploaded, the thumbprint matches (in this example it's also "1234567890")
ServiceConfiguration.csfg:
<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="myApp" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" osVersion="*">
<Role name="www">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
</ConfigurationSettings>
<Certificates>
<Certificate name="STAR.foo.com" thumbprint="1234567890" thumbprintAlgorithm="sha1" />
</Certificates>
</Role>
</ServiceConfiguration>
Azure Console:
I have verified that:
My cert is uploaded
It's SHA1
It's thumbprint matches what I've specified in ServiceConfiguration.cscfg (in this example it's "1234567890")
The certs for the Certificate Authorities are also present (for me it's "PositiveSSL CA" and "AddTrust External CA root")
For the Azure instance, it confirms there are 2 endpoints (port 80 and port 443)
Why would I not be able to connect at all via https://foo.com, but my https://foo.cloudapp.net will load (although triggering a browser warning)? This seem to indicate my configuration is correct but something else is off... ideas?
I think you may be looking in the wrong place for your problem!
How have you mapped foo.com to your site's address?
Note that Azure instances are given dynamic IP addresses - what address your site may be on NOW may not be what its on tomorrow. The recommendation for Azure is to add a "www" CNAME DNS entry in your domain records that points at "foo.cloudapp.net".
This way, when someone browses to www.foo.com, the DNS server will (invisibly) say "hey, actually, that site is as foo.cloudapp.net. The browser will then ask for the IP address of foo.cloudapp.net. This domain is managed by Microsoft who will return the current IP address for your site.
If you want foo.com to still get you to www.foo.com, you'll have to setup DNS redirection so that whenever someone types foo.com into their browser, they're redirected to www.foo.com. This will then cuase the browser to resolve foo.cloudapp.net and then the HTTP request will be sent to your site. Some domain hosters charge for this (typically a nominal fee), some offer it as a free service.
HTH.

Using WCF on Localhost on Azure

In summary
How do I acces a WCF service on localhost when hosted in IIS on Azure? Azure does not bind localhost or 127.0.0.1 to my website.
Details
I have an ASP.Net application hosted on Azure. I have added a .svc and some workflows that I want to use via WCF. To keep matters simple, my web app simply calls the service on localhost, so I have endpoints like these in web.config;
<client>
<endpoint address="http://localhost:8080/Router.svc/Case" binding="basicHttpBinding" contract="NewOrbit.ExVerifier.Model.Workflow.Case.ICaseWorkflow" name="Case" />
<endpoint address="http://localhost:8080/Workflow/Case/Case_default1.xamlx" binding="basicHttpBinding" contract="*" name="Case_default1" />
</client>
This works just fine on my local machine. The problem is that when I publish this to Azure, the Website in IIS does not get a binding to localhost, instead the bindings are always to the actual IP address of the server.
It ends up looking like this in applicationHost.config:
<bindings>
<binding protocol="http" bindingInformation="10.61.90.44:80:" />
<binding protocol="https" bindingInformation="10.61.90.44:443:" />
<binding protocol="http" bindingInformation="10.61.90.44:8081:" />
</bindings>
So, as soon as my web app tries to call the service on localhost (or 127.0.0.1 for that matter) it fails instantly.
Needless to say, if I rdp on to the server and change the binding then all is fine.
What I find really odd is that there are tons of examples out there where people are accessing WCF services on localhost on Azure so I can't figure out why this is so. I have set the osFamily to 2 and in order to debug this I have enabled web publishing and remote desktop access which I guess, in theory, could mess things up.
What I have already looked at
I can rewrite the end-point address in my code at runtime to substitute localhost for the actual address or create the endpoint dynamically as described by Ron in the answers. Unfortunately I am using the WCF Routing service so I can version workflows. This means that my code calls the Router endpoint and the WCF Router in turns calls the actual service/workflow using an endpoint specified in web.config. I don't have control over the Routing services endpoint resolution without, I think, writing a whole set of routing logic which just seems to be a lot of work when all I want is to call localhost :)
Switching to using named pipes; Alas, it causes some strange issues with workflows, probably due to duplexing, and I am on a deadline so haven't got time to get to the bottom of that at the minute.
You have to build the endpoint address dynamically.
Step 1:
In your ServiceDefinition.csdef you need to declare an Endpoint.
<ServiceDefinition name="MyFirstAzureWorkflow" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="WorkflowWeb" vmsize="ExtraSmall">
<Sites>
<Site name="Web">
<Bindings>
<Binding name="Endpoint1" endpointName="WorkflowService" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="WorkflowService" protocol="http" port="80" />
</Endpoints>
<Imports>
<Import moduleName="Diagnostics" />
</Imports>
</WebRole>
</ServiceDefinition>
Step 2:
When you want to call the service
var endpoint = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["WorkflowService"].IPEndpoint;
var uri = new Uri(string.Format(
"http://{0}:{1}/MyService.xamlx",
endpoint.Address,
endpoint.Port));
var proxy = new ServiceClient(
new BasicHttpBinding(),
new EndpointAddress(uri));
Okay, so this is how I solved it. IMHO it's a hack but at least it works.
Basically, I need to add a "*" binding, so I can do this in Powershell. The general recipe is here: http://blogs.msdn.com/b/tomholl/archive/2011/06/28/hosting-services-with-was-and-iis-on-windows-azure.aspx
That deals with adding Named Pipes support, but the principle is the same. I just changed the Powershell script to:
import-module WebAdministration
# Set up a binding to 8080 for the services
Get-WebSite "*Web*" | Foreach-Object {
$site = $_;
$siteref = "IIS:/Sites/" + $site.Name;
New-ItemProperty $siteref -name bindings -value #{protocol="http";bindingInformation="*:8080:"}
}
This now allows me to use http://127.0.0.1:8080/service.svc to access my service.
Note: You do need to follow the rest of the recipe to set elevated execution context and change the powershell execution mode, so do follow it carefully