On an ASP.NET website hosted on Azure, I need to secure a page so that only certain users can access it. Because of a javascript library used in the page, it will work correctly only when served over HTTP, but the ASP.NET authentication will not allow access unless the page is served over HTTPS.
To limit access to the secure page, I added a Web.config file to the folder containing the page:
<configuration>
<system.web>
<authorization>
<allow roles="Admin" />
<allow roles="Map Viewer" />
<deny users="*" />
</authorization>
</system.web>
</configuration>
The main web.config file sets up forms authentication.
<authentication mode="Forms">
<forms loginUrl="~/account/login/"
requireSSL="true"
timeout="2880" />
</authentication>
This works like a charm if you access the secured page through https (e.g. https://example.com/Map). You are prompted to log in, you enter your credentials, and then you go to the page. As noted above, the page will not work correctly if served over http. However, ASP.NET authentication/authorization won't allow you to access it:
1. If you are not logged in and try to access the page over http, you are redirected to the site home page once you log in.
2. If you are logged in and try to access the page over http, you are shown the log in screen even though you are already logged in.
No other secure pages on the site require HTTP to work correctly, and this form-based authentication process has been working fine for those pages for years.
Set the requireSSL attribute to false, or remove it (requireSSL is false if no value is specified). If requireSSL is set to true, then the server will not accept authentication cookies unless they are sent to the server over an HTTPS connection. When this attribute is removed, the server will accept authentication cookies from both HTTP and HTTPS.
Related
In ASP.NET web app, I have login.aspx.
I force that every user access through Login.aspx, setting that on web.config:
<authentication mode="Forms">
<forms name="coockie_aut" loginUrl="login.aspx" protection="All" path="/" timeout="60" slidingExpiration="true"/>
</authentication>
My question is:
Using form authentication and loginurl, would it prevent from trying to hack any web page without accessing first Login.aspx? Does it mean that allways allways there will be forced to access Login.aspx first?
That depends what you mean by "hack". Default Forms Authentication will redirect any request with no session authentication token to the login page. There are all kinds of session stealing, man-in-the-middle, brute-force, and other varieties of attacks that you may still be vulnerable to.
we're using ASP.NET Membership for authentication at the root domain (www.domain.com) and the redirecting the user to a subdomain (sub.domain.com). When the user logins in from www they are being redirected to the login page on the subdomain when they should be showing as logged in instead.
Both the machine key and the forms element in the web.config are identical.
In the event log we get
Forms authentication failed for the request. Reason: The ticket supplied was invalid.
turns out it was a MS Security update that did it.
UPDATE
security update available
What's worked for me is to set the domain attribute of the forms element to be .domain.com. This should allow the user to log in on at www.domain.com and then be logged in when accessing sub.domain.com. I've tested this having hacked my hosts file and it works okay.
<authentication mode="Forms">
<forms loginUrl="~/Account/Login.aspx" timeout="2880" domain=".domain.com" />
</authentication>
I have a shopping cart asp.net application presently i manage login system by simply making a DB table with 2 field username and password and in my web.config file redirect all the user to login page by authentication and authorization tag
<authentication mode="Forms" >
<forms defaultUrl="default.aspx" loginUrl="login1.aspx" cookieless="AutoDetect" ></forms>
</authentication>
<authorization>
<deny users="?"/>
</authorization>
and on my login page simply compare username/pwd entered by user with database entry and if the user is correct calling the function
FormsAuthentication.RedirectFromLoginPage(username, true);
that redirect the user to home page it works very fine on my local system and i have no issue.But recently i hosted my application online and there is some issue with my login system.When i login into the site its ok but after some time user is automatically thrown out of site to the login page and he has to login again.
It sounds like your users are bumping up against a cookie expiry. Add the following attributes to your <forms> element:
<forms defaultUrl="default.aspx" loginUrl="login1.aspx" cookieless="AutoDetect" slidingExpiration="true" timeout="60" />
By default, sliding expiration SHOULD be set to true, but if it's not, 30 minutes after a user logs in, their authentication will expire no matter if they've visited other site pages since that time. By default, the timeout period is also supposed to be set to 30 minutes from last refresh, so if your user is idle for 30 minutes, they will have to renew the authentication cookie in order to access secured content. You can extend this to whatever value you like, such as "60" in the above example.
You can find out more about these attributes at the MSDN reference page.
I have a set of WCF services with AspNetCompatibility enabled and consume them from jQuery. My web application requires authentication. Using only logic here (as I lack enough knowledge) does that mean WCF will be accessible and limited only to currently logged users? I know one can catch communication data and try to reuse it later (I don't have ssl) but for that he should be logged in.
Right, wrong or just stupid in my own optimism?
Yes, because you have ASP.NET compatibility enabled and because you're using ASP.NET security, as long as you have the proper <authorization> setting for the WCF resource it should be secured by ASP.NET security. At bare minimum this means you should have authorization defined as follows on the WCF resource:
<authorization>
<deny users="?" /> <!-- deny all anonymous users -->
<allow users="*" /> <!-- allow all authenticated users -->
</authorization>
Only if you allowed "*" would your WCF service be inaccessible to non-authenticated users.
You can read more about this here in this MSDN article under the section titled Hosting WCF Services in ASP.NET Compatibility Mode.
I am deploying a public ASP.NET website on an IIS7 web farm.
The application runs on 3 web servers and is behind a firewall.
We want to create a single page on the website that is accessible only to internal users. It is primarily used for diagnostics, trigger cache expiry, etc.
/admin/somepage.aspx
What is the best way to control access to this page? We need to:
Prevent all external (public) users from accessing the URL.
Permit specific internal users to access the page, only from certain IPs or networks.
Should this access control be done at the (a) network level, (b) application level, etc.?
I found the best solution was to place an irule on our F5 load balancer.
We created a rule that the load balancer would drop all external requests for the specific directory. Internally, we could still hit the pages by connecting directly to the servers in the farm.
Here is how to secure specific page for specific users and only them
<configuration>
<location path="admin/somepage.aspx">
<system.web>
<authorization>
<allow users="User1,User2" />
<deny users="*" />
</authorization>
</system.web>
</location>
</configuration>
To set allowed IP you need to configure web site in IIS via IPv4 Address and Domain Restriction where add a wildcard Deny Entry and specif Allow Entries.
Also you can setup all this programmatically.
A simple implementation would be to set File Security on that File in IIS to Integrated Windows Authentication only.
Then in that file's code behind, check for the user's ID..if they are authenticated, they will have an ID, and let them access the page.
if(!HttpContext.Current.User.Identity.IsAuthenticated)
{
//Direct user to other page or display message.
}
When users go to that page, it will ask them for their network login