I am using shibboleth SP 3 and IIS 8 on one server. I protect a folder "secure" and redirects to a test ADFS, where I configured the extraction of the UPN from the AD.
My attribute-map.xml looks like this:
<Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Attribute name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" id="UPN" />
</Attributes>
Everything works fine. I check the http headers and server variables, all the custom shibboleth headers are there and corresponding server variables with the prefix HTTP_
I am deploying this on a test server, Windows Server 2012 with IIS 8. My problem is, I still have the server variables, but without the HTTP_ prefix, and I don't have the HTTP headers any longer, while my app relies on them.
The configuration files are almost identical. I have dug in the Shibboleth SP wiki, which is a murder to read, I don't find where I can finetune how the attributes are added in HTTP headers or server variables.
Do you have any clue?
thanks.
Shibboleth SP 3 uses the new iis7_shib.dll instead of the old isapi_shib.dll and it no longer populates the headers by default. See https://wiki.shibboleth.net/confluence/display/SP3/IIS#IIS-NewVersioninV3oftheSP.
However, you can edit the <ISAPI> element to useHeaders... see: https://wiki.shibboleth.net/confluence/display/SP3/ISAPI for documentation, but it should be as simple as replacing
<ISAPI>
with
<ISAPI useHeaders="true">
within your shibboleth2.xml file.
Related
We are trying to remove references in the headers to ASP.Net
In our .Net MVC project, the web config contains:
<sessionState mode="InProc" customProvider="DefaultSessionProvider" cookieName="newCookie">
In the host headers when viewing through the web server (IIS) I see:
ASP.NET_SessionId=....
newCookie=.....
However when I test locally, I don't see the ASP.NET_SessionId reference.
I also renamed the forms authentication cookie name to something else.
What am I missing?
Rundown
So I've continued tinkering with this. This is a new Windows Server with IIS 8.5. I've never had any problems getting CORS to "just work" in IIS so I've never really needed to care about the fiddly bits in the server config. The immediate fix was the shotgun approach; I enabled CORS server-wide with the following modification to applicationhost.config
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
but removing this customHeader and setting [EnableCors(origins: "*",headers: "*", methods: "*")] inside my controllers does not cause the server to send back Access-Control-Allow-Origin response headers (yes, I made sure to call config.EnableCors() in my HttpConfiguration.
An additional complication is that using this method, I have to allow all origins because I need several origins to be able to access this server. Browser implementations do not permit multiple origins to be sent back from the server in this header. I could always write my own EnableCors logic within my application, but would rather understand and fix the server config to stay on the res.
Original Question
So I'm running into a bit of an issue trying to get a Web Application deployed to IIS 8.5 on a fresh Windows Server 2012 R2 straight from our server provisioning team. My application is a Web API with Cors Enabled, (currently allowing all origins) but the server is not returning an Access-Control-Allow-Origin header to calling clients. I've never had an issue with Web API Cors "just working."
I found this resource, but confirmed that the OPTIONSVerbHandler had already been removed within my application's web.config.
I tried to add a customHeader to IIS, but whenever I did that, the server started returning 500s.
Is there anything that I can do to force IIS 8.5 to send Access-Control-Allow-Origin headers from ASP.NET?
Edit1
So I apparently installed the ASP.NET Cross Origin Resource Sharing NuGet package into my solution rather than the ASP.NET Web API 2.2 Cross Origin Resource Sharing NuGet package. I swapped these out and I have limited (but still unexpected) CORS functionality. I'll describe the weirdness I'm experiencing now.
So before I realized I had the wrong NuGet package, I had gone into applicationHost.config and added
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
in an attempt to get the server to push the header back manually. Without the NuGet update, this did not set the header on preflight responses but at this point I'm not quite sure if that was due to me forgetting an iisreset;I was trying to move fast.
At any rate, when I added the Web API 2.2 Cors NuGet package, my server responses started emitting an Access-Control-Allow-Origin header with wildcard origins rather than the ones that I had set in my EnableCors attributes inside my Web API routes. So with that value, I knew that it was the configured customHeader rather than the EnableCorsAttribute that is now controlling the value.
(Here's where the weirdness comes in)
So I would actually prefer to be able to directly control the CORS whitelist directly at the server level, so I went ahead and set the customHeader to
<customHeaders>
<add name="Access-Control-Allow-Origin" value="http://segment.mydomain.com" />
</customHeaders>
where http://segment.mydomain.com also matches one of the allowed origins inside my API routes.
I now get the proper Access-Control-Allow-Origin sent back from IIS in the PreFlight request, but the subsequent POST returns a 500. If I remove the EnableCors attribute from my Api Route, the POST succeeds (confirmed by directly querying the database that persists the posted data)
...wt*?
Edit2
So that hopeful approach (statically defined origins inside a customHeader in IIS rather than allowing developers to list their origins directly inside controllers) won't actually work. I need to whitelist multiple origins and Chrome's implementation only allows one origin to be set in the ACAO header. It also will not allow wildcard segments in origins, so...that sucks.
I would appreciate any hints regarding the following issue:
The problem summary:
While using Negotiate:Kerberos in IIS 7.5, the authorization works correctly right until we setup URL rewriting (using the MS module "URL Rewrite 2.0") - any rewritten URL then returns "401.1 Unathorized" (requests not matching any rewrite rule keep working though).
The setup:
Windows Server 2008 R2 x64
IIS 7.5
URL Rewrite 2.0
Server is in a domain
SPN exists for HOST/hostname and HOST/hostname.domain (created by default)
Pool is using default ApplicationPoolIdentity (no custom account, not network service)
Kernel mode set to OFF
Authentication providers set to "Negotiate:Kerberos" only (no NTLM or annonymous)
URL Rewrite rule as as "^(.*)/$" => "index?x={R1}"
The result:
1) When accessing any URL not matching any URL rewrite pattern, Kerberos is working correctly, i.e. Kerberos ticket is issued (verified using klist), sent (verified using netmon and HTTP headers) and accepted (verified by URL being accessible and appropriate AUTH_USER property set to my domain account name) => no problem here.
2) When accessing any URL matching URL rewrite pattern, e.g. "hostname/foo" the result is:
HTTP Error 401.1 - Unauthorized
You do not have permission to view this directory or page using the credentials that you supplied.
Module WindowsAuthenticationModule
Notification AuthenticateRequest
Error Code 0x80070055
Requested URL http://hostname/index?x=foo
Physical Path D:\wwwroot\
Logon Method Not yet determined
Logon User Not yet determined
(if we try to access the rewritten URL directly, e.g. hostname/index?x=foo, Kerberos works again normally)
The attempts to solve it so far:
After googling, we have tried several options:
turning kernel mode ON: Kerberos stopped working completely, using either default pool identity or network service (I suppose we would need to setup additional HTTP SPN and/or use custom domain account with additional SPN for that account explicitly)
turning "useAppPoolCredentials" ON: no difference
enabling "Failing Request Tracing": surprisingly these failing 401.1 requests ARE NOT generating any output into the fail logs no matter what rule we try to setup (e.g. 400-999) - the folder is just empty (while other errors, like 404 or even handshake 401.x when accessing not-rewritten URLs are generating logs - very strange)
The conclusion:
So far we have reached a dead end - it may be some weird kind of "double hop" issue requiring using a custom domain account rather than default app pool identity, but as we're in fact accessing the same resources, it seems more like a URL Rewrite issue.
Any tips, hints, pointers? Anything would be highly appreciated.
Best regards,
Marek
we face the same issues as you do. By enabling extended error logging, we were able to put the finger on the actual problem, which seems to be a bug in the rewrite module (or at least in some part of IIS, which is related to the module):
When the URL gets rewritten, the access to the new rewritten URL is checked (seemingly hardcoded) using Basic Authentication and NTLM, neither of which has been configured on the Website at hand. The only configured authentication provider is Kerberos. Since the client doesnt send NTLM nor Basic credentials, there is no way this can work.
We (another person on the current project) are sending the issue to Microsoft. I will let you know, when I get any result.
It seems as though you have multiple issues here.
Failed-Request Tracing Logs
To fix your missing logs issue, you must make sure that the user that is running your site's AppllicationPool has read/modify rights to the folder where those logs are generated, otherwise you won't see anything. See the section labeled "Enable Failed-Request Tracing" on this page: Troubleshoot Failed Requests Using Tracing in IIS 7
What isn't clear is the fact that the site's Application Pool Identity (found in Advanced Settings for Application Pool) is the account that needs read/modify rights to that folder.
Once that is fixed you can load the XML logs in IE and see a much clearer picture of what is going on.
401.1 - Unauthorized Issue
A possible fix to your 401 error is to make sure unlisted file name extensions are allowed in Request Filtering. Go to IIS --> Sites --> [your site] --> Request Filtering
You have two options here:
Allow File Name Extension... and add the value "." (minus the quotes), see this answer.
Edit Feature Settings... and enabled the option "Allow unlisted file name extensions"
The 1st option should work well, the 2nd option obviously opens up a gaping hole but allows everything so you should be able to get it working.
I hope that helps.
I'm trying to use jquery dataTables with a few extras on Azure Websites. It generates a sizeable query string (2121 characters in testing). This returns a bad code on Azure websites (The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.).
To get it working locally I edited the web.config with this:
<httpRuntime maxQueryStringLength="4000" maxUrlLength="4000"/>
(I believe only the maxQueryStringLength is really needed).
Anyway, all is fine locally and on another server but on WA Web Sites I can't get it working. Any ideas?
Try customizing IIS Request Filtering parameters.
I suspect you're using Cassini (Visual Studio development server) to develop locally.
Limitations related to Query String and/or URL max lengths occur at two levels on Azure Websites (or any IIS environments) :
ASP.NET Runtime : These limits are lifted using the httpRuntime node and its associated attributes
IIS Requests Filtering module : IIS also applies its own filtering rules regarding URL and Query String length, even before the request is processed by the ASP.NET Runtime. By default, the maximum allowed length for a query string is 2048 (see here). You should set the appropriate values in your Web.config, under the requestLimits subnodes, eg :
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString="4096"/>
</requestFiltering>
</security>
</system.webServer>
See also this question
I'm not sure if this was a change in IIS 7 or if someone before me actively removed X-Server from the HTTP response headers but I need to be able to tell which server in the farm served the current page. I don't see X-Server in the custom variables section of IIS but I'm not sure if it was a custom variable in the first place or if it's in the defaults and it's been disabled via web.config. How do I get my headers back?
You can use custom headers (http://www.iis.net/ConfigReference/system.webServer/httpProtocol/customHeaders) to add any header you like.