II6 Basic Authentication and RouteTable.Routes - asp.net

I have an ASP.NET 4.0 WebForms site that is running on a IIS6/Server 2003 instance. The site itself does not permit anonymous access and uses IIS basic authentication before the user can get to the Forms authentication screen. However, there are two site nodes below the site level, that are virtual directories which DO permit anonymous access (for requesting static images by other machines).
A new request required me to route those requests to a different page and examine the URL being requested and perform different tasks. I’m using a MapPageRoute method in the Global.asax file and the route clears through Forms authentication with a web.config setting <allow users="*" />. Obviously, that works great locally, but when deployed to the IIS6 machine basic authentication kicks in before the request gets routed.
Is there a good way to "fake" or create a virtual directory node in IIS6 and grant it anonymous access so that the routed url request can execute?

This might not work for everyone, but since in my case HTTP Authentication was primarily instituted just to prevent people from multiple attempts at the login page, I actually removed Basic Authentication from the site and all virtual directory nodes.
Then I added it just to the ~/[loginpage] that was being used. Since forms authentication was in use all unauthenticated users are re-directed to the login page and then get the basic authentication. Since the routed page request needed to be public I just added it as an exception to the Web.config. The routed values have to meet a very strict criteria to even be executed by the page logic and everything else is returned as a 404 by the handler.
Obviously this means that the asp.net dll is executing before IIS basic security when requests are redirected to the login page, but in this case I think it is fine.

Related

How to block access to Web API , except from the ASP.NET Web Application

I have a website in IIS say abc.com
Now i also have a asp.net API as virtual application within abc.com
I want to restrict all direct access to the API , except from the website.(browsers, postman, fiddler , etc)
Within the API, I tried to detect ip from which the request was made
context.Request.ServerVariables["HTTP_X_FORWARDED_FOR"];
context.Request.ServerVariables["REMOTE_ADDR"];
Although the above may help detecting client ip , it may do little to help in preventing outside website request to the API
How can I accomplish this?
Thanks for any pointers.
Does the web site require logons, and did you implement security? Any web service call (to a static method in a existing aspx page, or even a call to a asmx page? if that page is placed in a folder that has security (in web config, as normally dropped in each folder to secure by security groups (roles)), then those web service calls from the browser simple will not work unless the user is logged into the site correctly.
For any web calls that you don't need or want security, place those aspx/asmx pages in such folders without IIS security applied, and no logon will be required to use such pages.
If you don't' have any security setup? Then it going to be rather hard to suggest you want security for the web site when there is no security setup?
So, even a simple basic FBA (the classic security setup) will thus be handled by IIS, and those web service calls can't occur unless the user is already logged in. So, your free to write and setup ajax calls from the client-side page, and you don't even have to worry about security in that client-side JavaScript code if the site has security setup.
If you don't have any security setup or applied to the site, then it quite much suggests that you don't have many options in the way of security choices.

IIS Forms Authentication throws a 401 Error

We are currently setting up forms authentication for our web app.
The plan is for users to be redirected to a login page on our main system when they want to access files.
IIS Settings
Setting the IIS "Authentication" to anonymous gives access to the files.
BUT when we change the authentication to "Forms" and disable everything else we are met with a constant 401 error when trying to access the file.
401 Error
There is no redirect. It just throws this error.
The Web config has been changes to allow "?" (anonymous) and allow="*".
This does not change the 401 error.
When anonymous access is enabled (alongside forms auth) there is no redirect. The users have direct access to the files. (As if forms authentication is not even enabled?
Web Config
Please note that I also had to add machine keys to my web.config and also had to add the domain name in the authentication tags (also in the web config). After also adding a cookie.domain in my C# side the authorisation is finally working between domains.
--This has to be done when working with 2 subdomains. Eg: 1.website.com and 2.website.com.

Forms Authentication and 400 Bad Request when redirecting from the login page using cookiless sessions and IIS7

I have a web app configured to persist logins if the user chooses. I am using formsauthentication and set cookielesss to autodetect. When cookies are used the ticket along with specifics about the user is properly maintained. When I disable cookies, I get the session identifier embeded in the url and directed to the login page.
However, I cant get the redirect to the default page to work using IIS 7. I get 400 Bad Request - URL
When I run the application in VS Using cassini the cookieless ticket and session work great.
I have tried the following:
set <httpRuntime maxUrlLength="15000"/> in web config.
Set the Request Filtering to allow for very long URL's (1000000)
When I authenticate and redirect in VS the redirect works and the URL looks like:
http://localhost:53605/(X(1)S(new25hbmvxqwiupj3uijv2et)F(HHRQfdcbjBvktt0SbfNrna7jUgMQYcA2q6uv8ptwjYoQCEIO3MgYD59wXfTdRPSnzdaoCnkKQF762Tiii98dEQdmUGiAYm5XrpIcwin_TcEWMRsHDIgrqsvULetKy97--XUWx3ESMkMRWNwwYNEoC65nqvG_-ip1g0y_9N52RwspzW__QFNberHNf9asniAQv8dtFkbClW8hKyjPYawaIzmLgFw-OfCVyVyIkrjONs7nu2TZCV7sQvgG-txTtiSJ_vtBYB81vbv3n2ZSrjHsft6zyodZh0yNbRGJUc1Vb0ee4iAJQnOJ-a4Plsgx1r3qwhw_dVhkl20Omr2V81o84sfhAhd_Ye0Y4CFJk8EakQ5yRf8GNQ7gyn5Je3RWqnoAiW_gdB7VMqB7-eX4RjTml4W1RJAN2QWa7S21w-A_KrD7oc1Cp6vAOwPt_kkBxhYTApUkPIsiFQ5kJ0RnPA6NJFal9BGD9JVS9YDHZS2MHQicR-kUang362AghpexjcIDPTE1QPTEslzfpB2RnoosTPunPK5a3L0_hwSwWllagbCHxHXEA_6d73UhFeX23QYzMG_1gYFhANj7vIT5e3nDuRL_6Yep22h8tzRKAly8mk3Ke5U1_lU0sMrgdjXIInnsVzCbLfN42rUVlJaGOM1kbzM68-P9bLvu_qyD1h1iZak_coDPPNpioxg1BTQ5fyon4kSd89qAvSoDslIn3xJxwCABeY63lKoElQjel1mkusI4i1woGww_wDhS6jvFGP3R-d7xJtpTNiXsNvBc-ZIrca_XF1Z-YDnGCTy6v85vCTj-aU4xPcj7eW4CHSFwLslsBjjvNbH6UAHT5YtFW6KTlXY15_KBp79cIqOqKIOD6HRjtHijiJkgEC_BU6KPFPZh5kDH1kPX3c0wg1cFAreFM_BLje2s7MErA4kBvTwRQJMbaShFv8QOcABxLAFscw1iFBSu7QjeT0ugDblc53PCwTrlLAs5X7KTDyHgRvcGvkGKvWmFdlzD3WHLtJRlbrgDfDbYI0rWDKkR6-K2Bg--VAuUs-HBRM0FFUb0znnwaKE52Hjr39xWE1CiWmkQrcEkNhDdo-_LCnnJbXCWYiwV8rtJcFjRvISsz2w7avIJDRiGEOKw3odAL5FXztHMcLMHMuQ-wiE1LXh0FmdbSd7goHNK6Ehmoda8FP2mzN2DZEIEx887F_HO9xjQcVlHRlnECvphvBRax6jkmmJ7VUGrYLM2zH7T9MTGtuTUTASxfpvp7IYq49NhytYEieoTqDuPYVxpT7_ACywrkOZOnHUeuTvKFfDuCofE1IH_QfnB1lBk29u2qvKJMSHP5Xb1aAsZ-9_dMVIN0klVZIqvby6Khw2))/Home/Dashboard.aspx
When it fails in IIS the url looks like :
http://localhost/Reports/(X(1)S(4a0qmf3mf5ebpgokpyog0beq)F(xQGpHp6u9P7tD7I5D8uLI7zZRylqaqssOk_930NAk5VlyED4DYAk5eAC-uPOwHl5EKUrILTmQYTTIiiELL1ILCdQ5EG1gRLsIR5wSIS5_EjW0ibRstbvXVPsdSZxQOT4Uwj-JjauRvTAYNWSdff0H3mvANX8mAfUhSuMKjy67HhGJZkQjFPqUYtll0xSdP8RJ-0lMzQ-uCWG9b2OiRPT35HRk6AiuKQPDUWZNjMRzKO9-NSfm_SQXHhq8wr4xbNXuBmyDmME1lpxl3BhB_Y86KZjl_9eklFOJ-oz8_dmyuEbZqvMzXYTSfC6sL95UlRfxgXkBHRdNzLdqvMD3_1Ke78fAKEEuE6JeUbEXpES76Q6M3NJpxwz1YlEMoC_PgV9s5EQtX65QZbxzML2kSyst38Eu_WLyCL-KKE3gAmEHSUhfZ1G5WXXOoSk__vgz1Od9SNUfjxsIyEK4-HstZMLGDNWXZZc7_DTlPGrXS6yr6NfjmJEixxKEpgP-HN3Q18YPyOcS5EUwGa3tISPjGKMGq5qmZcRyihwAImUA0X5lh-rgNvWNM5AkPK8F7fAzygNJ7CZMmKN87wiCsC8kDthKZrOhbzgO4EOTsv0gEnSe7wiSH4vWzrEumUrJDGrFGLmtudyl4hLgAwQcSdMh2OIapGNVAPQTwEqwqc4kEZnWpGxXrfPxejG-IH391TFqHLyYWkN5onVXWhOn3cCeYNqD0yc7jgOZ_AY4gTj4UtiB_PAK4jlRhwyQ4SozJzkSQFimtURC-H6Z7piB6ekXIihtAdTURTpaq6CmKefCh6ydgDJNywS9nFoFBKPUdi3kF9hpuz9yNtfz8zh4LAm6ikP2p0yXBpecQq2W7V6XFJhVXC00Hvx56kvks-r1V4660-WDsvee86-4GID1XBcM7AoOWfkvABWMRDLjixk8ud57QlyJ_kYmHTeIQWDuj3EA1a6383ffycVdx3AFJ8px3eNacHybKX-9kwoYJaoo_T019ZvrcgrNWeK4uEf3VRVYVRydkJoW4Pk6OgDRN1LvSYkwEjGiN_m2g03MLfpboLMtGzorBSjTwvId8u_CqqBB4QAqj7Vt4htU6jfKWlERlqo38dTdub0i69eLAJffVoTEH2wIhqIpRp6WIWk8NNh97AkqYAOR5744cNuqJBJI56ZsY7Ja31wPArJI4nO1ey49CzReI3W5I9MWW2TuWE3x2XjFxXbea_4uTv5CdhGOYqsd5IugFMLz-0Rcva77ZI-ZipISwzv62ZXAGaQKg6PuVWIEGtTs9K_B-h3Dhg3anjxNOS7t03U6v4d9lyNwtmN4nK4-29NUAf2DcPo7V4TQzc-TtTpv-4gcvA_U47HijfasQ2))/Home/Dashboard.aspx
The only difference is the webdev server loads the application at the web root. I tried adding a blank test page to ensure there are no resources outside of the page being requested and it still fails.
Any suggestions?

Redirect to Web Service WebMethod from ASP.NET Website

I have a website created with ASP.NET and a web service, both using FormsAuthentication (which validates the user's credentials against Active Directory - LDAP).
When I call an action method of this web service for the first time I am redirected to the site's web page that actually logs the users into the system. When I'm logged in I will be redirected to the web service (ReturnUrl), but I'm guessing something gets lost in the way, because I'm getting an InvalidOperationException (in the client), containing the .asmx definition.
This happens on the first call only, the next calls work fine (since I'm going to the right place).
What am I missing here?
How should I redirect from the web site to the web service? Can this be done?
Thanks in advance.
Your web service call is doing a Post, then redirecting via a Get request after authentication. The default response from an ASMX is the .wsdl definition. You can't do web service authentication like this programmatically.
If you are using Active Directory, why not use Windows Authentication and suppress the login?

Using Identity Foundation with a WCF Web Api

I have a bunch of websites that are setup identically to use a WIF identity provider. I've recently moved the business logic out of the web applications and into a Web Api service application. This runs in a different virtual directory to the other sites. The idea being that browser will put the data into the page AJAXy.
The issue I have is with securing the web API. It seems that WIF single sign-on works okay with traditional sites. The user can access one website, get redirected to the identity provider, login and get redirected back to the website they wanted. When they access another site they also get redirected back to the identity provider but needn't log in as a FEDAUTH cookie exists so they automatically get authenticated and redirected to the second site.
This doesn't work for the Web Api scenario because when the browser perhaps makes a GET to it, the Api will return a redirect to the calling javascript when it should be expecting JSON.
Is it even possible to secure Web Api with WIF?
Not sure whether I got you right, but it seems like the main problem is that javascript/ajax does not support http redirects.
A possible solution could be to simulate the redirection with a sequence of seperate calls in ajax:
Check whether you are authenticated on your web api site (by a dummy ajax call).
If this is not the case:
Call your sts over ajax and grab the security token out of the "wresult" form field.
Call the login site on your web api site and pass the security token as "wresult" data.
Dominick Bayer wrote a few blog posts about securing rest services. For further reading have a look at http://www.leastprivilege.com/. (Especially http://leastprivilege.com/2009/09/11/adding-a-rest-endpoint-to-a-wif-token-service/ and
http://leastprivilege.com/2010/05/05/thinktecture-identitymodel-wif-support-for-wcf-rest-services-and-odata/).
The following presentation from TechDays might also be interesting: http://www.microsoft.com/showcase/sv/se/details/ffc61019-9756-4175-adf4-7bdbc6dee400 (starting at about ~ 30 minutes).

Resources