What is the best way to password-protect a folder on IIS with a single set of credentials to be shared by a group of users?
Our hosting service offers Plesk, which in turn offers a "password-protected directory" function, but some of our clients have HTTP authorization disabled, so they get an automatic 401.4 error with no prompt for credentials.
I've looked into Forms authentication but this seems cumbersome to set up for the numerous separate domains at issue.
The protected content is not super sensitive, we just don't want it easily accessible to the public. Many of our users do not use the site frequently and we don't want to implement individual credentialing for everyone (we do have that in place for more sensitive sections) just so they can view current project reports or meeting minutes.
On sites I don't control, but am just a user, that do the same things as mine, it is a big pain to have to look up a username and password twice per year just to view a meeting agenda (yes, browser could remember but they also have a 4-month expiration and lots of us are on different devices all the time).
Is Forms authentication the way to go? Took a several hours for me to get it set up and working, with all sorts of settings not well documented in a single place.
(I had previously asked about how to disable Basic Auth on the client side, was told more than once it's not possible - but it is, via client/browser registry keys)
Thanks.
It's perfectly fine to use forms authentication. All you need to do is navigate to the folder or file you want to protect, then go to Authorization Rules. Add a deny rule for anonymous users, when users who are not logged in try to click on any file in that folder, they will be redirected to your login page. You can find a lot of guides on forms authentication in Google, you can refer to the following:
https://learn.microsoft.com/zh-CN/troubleshoot/developer/webapps/aspnet/development/forms-based-authentication
https://learn.microsoft.com/en-us/iis/application-frameworks/building-and-running-aspnet-applications/how-to-take-advantage-of-the-iis-integrated-pipeline
Related
We are trying to allow our business users to be able to verify a new site's production look and feel as well as to allow a select group of internal users to be able to view new sites that are authored and created in AEM.
One idea, is to set up a Launch Page that the general public would see, and for the pilot group, they would set a cookie in their browser to be able to see the pilot site.
We have looked into VHosts settings, but can't spot anything, and are thinking perhaps a conditional pass through rule based on the cookie in the header as being the easiest approach?
Any thoughts would be greatly appreciated.
I had error when access SharePoint sites out of the server , as when I
try to add new document or did any action this error displayed although
it worked well in SharePoint server
I think Yevgeniy made a good suggestion.
I assume you mean by 'outside' the server, users are trying to view the page on a different URL? If so, it might be the URLs to access the site 'outside SharePoint' are not configured correctly.
I would suggest a few things to start with:
When you say it works 'in SharePoint server' does this mean that the whole site is accessible, with no problems? But using a different URL (i.e. host header?), fails - for just this one page with the list or the whole site?
Check you have Alternate Access Mappings configured correctly as suggested above - check that the URL is setup correctly in any AAM zones defined, and that the authentication (e.g. Anonymous, Forms whatever required) is also setup too. This is all done in Central Administration.
If AAM setup correctly, check if you have any firewall or other network security that may block access to the site (again, assuming users are routed externally?)
Does the problem page or list (or the subsite it is within) have any unique security permissions?
You can check for the site via Site Actions | Site Permissions - if it does not have unique permissions, you will see a 'This Web site inherits permissions from its parent.' message.
If the List has unique permissions, you can check by going to the list page, and clicking 'Library Permissions' on the Library grouping on the Library Tools section of the ribbon.
Currently Azure Websites don't allow custom SSL certificates, but they have wildcard SSL enabled for the *.azurewebsites.net domain. I need a secure login form for my web app, but with no custom SSL, it appears that I'm SOL.
Is there any kind of workaround for this? Would it be possible somehow to have a login form at https://mydomain.azurewebsites.net that creates a forms authentication ticket that will then work at http://mydomain.com?
Couple of months ago I had exactly the same problem i.e. application was built on Azure Websites, had to run on custom domain other than *.azurewebsites.net and had to allow secure login process.
Workaround for that we used was to embed an iframe (using secure protocol and .azurewebsites.net domain name e.g. https://oursite.azurewebsites.net/login) into non-secure page on custom domain (e.g. http://mysite.com/login). And entire login process was performed in the iframe.
There is one thing which you should be aware of, namely, lots of customers checks whether the page where they provide their credentials was using secure connection or not. In our case, secure iframe in non-secure page was causing lots of customer complains. Workaround for that problem was to put a message confirming that the login process uses secure connection. The message made some improvements, however, still certain number of customers complains remained.
I hope that will help.
This isn't really an answer to your question, but Microsoft are very aware that custom mapped SSL to websites is one of the most requested features for Azure websites and they have said they are working on it.
Scott Hanselman himself confirms it here
In the meantime, Tom's answer is a perfectly valid workaround.
One thing I would be very wary of though is with something Tom brings up: the security warning that the browser will present. You'd be amazed how many people freak out when they see that message and don't go any further! We have a fairly active ecommerce site and there have been occasions where we have accidentally used a none secure image path on an SSL page and we have always received emails from customers asking if our site has been hacked or similar!
The disclaimer that Tom mentions is a good idea, but I think it will still put some people off.
I am working directly with the WAWS team right now to produce some public guidance for this. A GitHub repository with the requirements is currently being evaluated by the team (I sent it over to them literally 1 hour ago). Hopefully, the solution will be approved and made public within a few weeks.
I can say this - the workaround won't be fully supported or much custom guidance given on its usage aside from the repository and accompanying documentation. SSL is, literally, the #1 priority for the product, and hundreds of people are working insane hours to make it happen for everyone. This workaround should also be considered temporary, as you'll no longer need it once the full SSL functionality is launched.
Whenever I login to one Google service, I am automatically logged in all their other websites on different domains.
What I want to know is how they are able to access the disparate cookies and sessions that belong on another domain.
I tried searching online but I couldn't find any information. I could probably pull out firebug and try to find out but I am sure someone here knows.
A Google Login works like this:
1) You login, normally at a login page that is under the Google.com/accounts domain.
1a) If you aren't on the Google.com/accounts domain, it is going to forward you there after you post the form. This can be found on sites like Blogger.
Once you arrive at the Google.com/accounts domain, they do two things
2) They set a cookie(s) that is specific to the Google.com/accounts domain, that are also only able to be sent over a secure connection. This is to verify your identity later on.
I say multiple because there are several cookies bound to the google.com/accounts domain. I believe that one of these is to make sure that all doesn't fail if secure connections aren't allowed
3) They set a cookie that spans all the domains using .google.com as their domain, because this will make the cookie available to any domain.
4) They forward you back.
5) If it is a site on a different domain, like blogger, they send along an authorization key in the URL. The page sees it, verfies it, and sets the cookie for a different domain. A technique like this can be seen using Google's Oauth.
Here is where that Secure Cookie comes in.
If you notice, whenever you go to a site after you close your browser, they forward you to the google.com/accounts path, where they reverify you under a secure connection, and then reset the subdomain-wide cookie. Then they send you back.
Furthermore, some sites like Google Adsense use the same technique as Google.com/accounts uses, by making a secure cookie on a specific path, and then using more global cookies to allow greater access.
Some of this is guessing, but given what a non-insider can see, I believe that is close to the truth.
Note: I literally spent like an entire month just browsing from Google Site to Google Site seeing how they did stuff. By upvoting this post, you are decreasing the sadness I have for having no life
Here is how our Tomcat webserver is currently setup. We are using jsp for the webpages.
/webserverpath/main (all public pages and the login page)
/webserverpath/secure1 (private pages)
/webserverpath/secure2 (private pages)
/webserverpath/secure3 (private pages)
I recently discovered that the authentication is very minimal. For instance once a user is logged in they can bookmark any private page, close the browser, open the browser back up and go to the bookmark and is never asked to sign in again (which turns out to be bad since we recently started disabling users). All of this was setup before I arrived. I'm wondering what can I do to add the proper security? Should I have all the folders under one main folder (ie /webserverpath/main/secure1, etc.) or just leave it alone?
Let me add that I'm newish to the whole website authentication stuff, having multiple websites in different folders like this and JSP itself.
You might start here: Declarative Web Application Security with Servlets and JSP
Generally, you probably want some session-based authentication that kicks people out of the private parts of the site if they aren't authenticated.