I'm trying to wrap my head around the secure flag on my applications cookies, in tandem with my different deployment environments and I'm hoping someone can help clarify.
My Application
A .NET 4.7.2 Web Forms application using Forms authentication. The login page sets 5 cookies in code, including the Auth token cookie.
What I'm seeing with the secure flag
On my local, non-https development environment running IIS Express, when I set requireSSL to true on the httpcookies element in the web.config. I can see in the browser that the secure flag is set on all the cookies (including the auth token cookie), but the app seems to work fine.
That already doesn't make sense to me because I thought the flag would tell my browser not to send those cookies...
If I set requireSSL on the forms element, then it seems to do what I would expect, it seems to prevent me from logging in because I'm on a dev non-https environment.
Does anyone know why this is? Why don't they both behave the same way?
Related
I have an application that uses 3rd party cookie for multidomain authentication, setting the cookie parameters: domain, httponly, secure, samesite none and expires, to work with the context
server domain: xyz.com
client domain: abc.com and qwe.com
In this way, the same authentication cookie works for both client domains. However, browsers have a privacy-focused initiative to eliminate 3rd party cookies. Safari and Brave have already implemented it. Chrome will roll out in 2022.
This new policy is breaking the way I add cookies with multidomain.
I've already researched how to solve this, without stopping using cookies, but I couldn't find a way, other than using the header authorization with the token stored in the browser's Storage. In this case, it is not a 100% safe and attackable solution.
Does anyone have any direction on how I should handle authentication with multidomain without relying on storing the token in storage?
I am playing with Asp.Net Web Api 2 creating a REST service with token authentication (under normal IIS 7.5, not express). Therefore, I've used the standard generated template that comes with Visual Studio 2015.
I understand the concept and the code too, did some testing wth Fiddler, getting the token, try to register etc. and I like the approach.
But there's 1 thing I don't understand and I miss that in about every article I've read about it:
what should be the IIS authentication setting(s) for the service?
By default, anonymous authentication is turned on and the other options
(forms, windows, basic) off.
If I understood correctly it shouldn't matter (because the OAuth Authorization Server and OWIN in the WebApi service should take over the complete authentication mechanism for the service, right?), or else all IIS authentication options should be turned off.
But I see that it does matter. Because if I want to execute a '/api/Register' POST method, it only works if I have anonymous authentication turned ON. If I turn it off, I get a 401.2 Unauthorized result.
But it seems so unlogic / unsafe to me to keep the anonymous authentication turned ON. I'd like to turn that off. Or do I have to have it turned on? And if so, why? Am I missing something?
I've also set the authentication method in my web.config to 'None':
(Only thing I changed in my web.config is the database connectionstring.)
Our Sitecore 6.6.0 (rev. 120918) based website can work over http as well as https. We also have a security requirement of making all the cookies to transfer over SSL regardless of whether the website is accessed via http.
We have achieved this requirement by using the requireSSL property in the web.config as described here: How can I set the Secure flag on an ASP.NET Session Cookie?
With this change, our public website works fine and when analyzed in Firebug, we can see that all cookies are "secure" even when the website is accessed via http.
But the problem is when I try to login to the sitecore admin portal via http, it throws the error The application is configured to issue secure cookies. These cookies require the browser to issue the request over SSL (https protocol). However, the current request is not over SSL. The only way I can access the sitecore admin portal is via https. Even with https, it gives some weird issues. After some time of use, it says that lot of admin users are logged in and I have to kick some out to get in. I also can't access the admin portal remotely.
Why is it that the public website works with SSL cookies, but the sitecore admin portal has issues with SSL cookies. Could it be and incompatible configuration in our site?
I think the problem will be that you have set <httpCookies requireSSL="true" /> which will set the cookies to secure, but also have to set the forms authentication:
<system.web>
<forms requireSSL="true">
/* forms content */
</forms>
</system.web>
As this would override the cookie setting. The problem is having that set on the forms section requires that the login happen over https not http. On your public website, you will only see this issue if there is a login form.
To fix this you will either have to enable SSL for your authoring system (which is recommended anyway) or put up with not using secure cookies.
MSDN: FormsAuthentication.RequireSSL Property
Based on the error message I'd guess the login is trying to set a cookie with the secure attribute when the connection isn't secure. This would of course succeed if the request was secure already.
As a workaround you may be able to use IIS Rewrite to redirect the request to /sitecore onto SSL prior to any cookies being set since I assume you do want all requests on SSL for content management.
I might also be totally incorrect here :)
I have a parent application in IIS7 which uses Forms authentication. Within that app, I have another application (not virtual directory) which I would like to inherit the parents forms authentication settings.
The authentication in the child app is not working, when i call System.Web.Security.Membership.GetUser() it returns null.
Both the web.configs have the same authentication sections, both are set to have the same machine key and both are using the same app pool. Does anyone else have any more ideas?
Thanks
Without a proper look at the applications its difficult to see what could be happening, however, I do have a suggestion. Previously, I've written a class the encrypts the username in a cookie using something like a session id as a hash.
The next app can then check for the cookie, decrypt the username and authenticate the user.
The only issue with this is the cookie access. It only works for apps with the same parent domain. E.g. A cookie of domain.com would be accessible to www.domain.com, app1.domain.com and app2.domain.com.
Another solution, that would get around the domain issue, would be a Shibboleth implementation.
If I set Windows Authentication to true in IIS7 and set Anonymous Authentication to false, I will get a WWW-Authenticate header. I assume this is the cue to the browser to popup the authentication dialog. I'm trying to figure out where in the ASP.NET pipeline the WWW-Authenticate header gets set (and what class is responsible for setting it it). I've done quite a bit of Googling and looking at WindowsAuthenticationModule and UrlAuthorizationModule in reflector but can't seem to pinpoint it!
Several modules in IIS 7 perform tasks related to security in the request-processing pipeline. In addition, there are separate modules for each of the authentication schemes, which enable you to select modules for the types of authentication you want on your server.
The one you are looking for is the WindowsAuthenticationModule, which performs NTLM integrated authentication. It is located in Inetsrv\Authsspi.dll.
The picture below shows the HTTP request processing pipeline mechanism of IIS7.
For a complete in-depth elaboration, including the above material, visit: http://learn.iis.net/page.aspx/101/introduction-to-iis-7-architecture/
That should answer all your questions :-)
If you have Windows Authentication set in IIS the authentication will occur between the client and IIS.
.NET may access the details when is set in the web.config but IIS sends the WWW-Authenticate header and manages credential exchange.
See more:
https://www.owasp.org/index.php/Authentication_In_IIS
http://msdn.microsoft.com/en-us/library/ff647405.aspx