CODEWITHSUNDEEP
corspreflight
david wendelken
david wendelken

Reputation: 291

CORS PreFlight not sending Credentials, Server wants to deny unauthenticated users

Scenario

IIS Webserver. Not a .Net Webservice. POSTing to Webservice.

.Net web application connecting to Webservice in a cross-domain manner.

Requirement

Webserver needs to require authenticated active directory users with single sign-on.

It is acceptable for the pre-flight OPTIONS test to accept an authenticated request, but any other request (including the POST after the OPTIONS test) must require an authenticated user.

Where I'm at:

I have a successful CORS cross-domain call working between the web app and the web server. I can clearly see the OPTIONS call working and then the follow-up POST call working.

Problem:

OPTIONS call does not send credentials. To get around this we allow anonymous users at the website level. Otherwise, we get a 401 Unauthorized error.

However, once we do this the POST no longer requires authentication. In fact, the webserver log shows that credentials are not sent in the post at all. That is unacceptable.

I need a way to either (a) force the OPTIONS call to send Active Directory credentials or (b) the webserver has to reject all unauthenticated non-OPTIONS requests.

Preferences:

For solution path (a), I'm pretty game for what it requires.

For solution path (b), would prefer an IIS setting or web.config setting. The webserver is written in python but I suppose we could create a c# webserver code unit that would invoke the python code that does the real work on the server.

Ideas?

Upvotes: 2

Views: 960

Answers (2)

sideshowbarker
sideshowbarker

Reputation: 88066

Citing the requirements in the question:

I need a way to either (a) force the OPTIONS call to send Active Directory credentials or (b) the webserver has to reject all unauthenticaed non-OPTIONS requests.

There’s no way to force browsers to send credentials in the the OPTIONS call. Browsers are required to omit credentials in all OPTIONS preflight requests.

See first step of the algorithm in the CORS-preflight fetch section of the Fetch spec, which says:

To perform a CORS-preflight fetch using request, run these steps:

  1. Let preflight be a new request whose method is OPTIONS, url is request's current url, initiator is request's initiator, type is request's type, destination is request's destination, origin is request's origin, referrer is request's referrer, and referrer policy is request's referrer policy.

Every request also carries a credentials mode:

A request has an associated credentials mode, which is "omit", "same-origin", or "include". Unless stated otherwise, it is "omit".

Because the first step of the CORS preflight algorithm cited above specifies no value for the OPTIONS request’s credentials mode, browsers must use the default "omit" for those requests.

Given that, you’re not going to find any way to get around this on the client (browser) side, so I guess you’re left with needing to fix it on the server side.

Upvotes: 2

david wendelken
david wendelken

Reputation: 291

This isn't the answer I asked for, but it's an answer that could solve the problem for some folks.

If you're getting hammered by CORS and you are just trying to do an intranet application, there's a way to turn CORS off.

It's possible to set group policies to do so.

Computer Configuration 
-> Administrative Templates 
   -> Windows Components
      -> Internet Explorer
         -> Internet Control Panel
            -> Security Page
               -> Intranet Zone  (and/or Trusted Sites Zone, depending)
                  -> Access data sources across domains  
                        (set to Enabled.)

You'll need to do the sys admin tasks of setting the policy, making sure it gets to the local box, etc. I'm not savvy enough on the details to write that part up. Sorry.

Upvotes: 0

Related Questions