I have a domain and a group of sub-domains that require authentication to access. I am currently using mod_auth to authenticate users (mod_auth basic) at the domain.tld level. My goal is for single sign-on between the domain and all the sub-domains.
Will these credentials carry on to the sub-domains automatically, or with a simple vhost config change, or is there a better method to do this?
mod_auth_basic
Browsers distinguish areas that require HTTP authentication by a combination of the URL root and the name of the authentication realm.
Take for example, two domains each with a realm with the same name:
http://one.example.com/ with the realm "Please enter credentials!"
http://two.example.com/ with the realm "Please enter credentials!"
First a user visits one, is asked for credentials and enters them. Then the user visits two, the browser recognizes that the URL is different and thus asks again the user for her credentials.
This is a good thing, because otherwise www.badguy.com could set it up so that your browser sends over your online banking login.
In short: there is no way to solve your problem with basic HTTP authentication and standard HTTP clients.
mod_auth_digest
You could use mod_auth_digest instead, since with that you can specify more than one URI to be in the same "protection space". However, with this authentication method there are two new problems:
It doesn't scale very well, because you cannot use wildcard domains.
Browser compatibility is not as good. (See the documentation on how to make it work with IE.)
Related
I'm looking to setup a login page on a subdomain for use with Auth0. Is it possible to have that login page serve auth for multiple other subdomains?
For example:
I want login.xyz.com to be the auth page for:
dev.xyz.com
staging.xyz.com
production.xyz.com
It is possible to set up your login page to provide authentication for different subdomains (you could even set it up for different domains). One thing you have to remember is that a user will only have to log in once, and then will use their session among the different subdomains. This is because the user will actually log in to login.xyz.com and the other subdomains will only get a confirmation from your authorization server that the user is authenticated (most probably in the form of an ID token, if you're using OpenID Connect).
Premise:
I have an existing application with its own ACL.
I've also implemented the CloudFlare WAF.
My client's organization has not yet implemented a VPN.
We are seeing a lot of false-positives from the WAF for normal behavior in the application's Administration panel and because there is no predictable IP or set of IPs we can whitelist, we're struggling to unblock Administrators without turning the WAF settings down too low.
I'd like to setup something like HMAC validation, but that seems to assume that the URL of every request include the MAC hash. Instead, I'd like to store that MAC has in a cookie and use something like the user's IP address as the message. It would look something like this:
User load Administration panel's login page
User authenticate's with the panels ACL
The first page load of the panel adds a cookie with the token {time}-{hash} where the {hash} is base64_encode(hash_hmac("sha256", $userIpAddress . $time, $secret, true)) (PHP)
Future requests from the Administrator's browser include this token cookie. CloudFlare's Firewall Rules check is_timed_hmac_valid_v0 [documentation] using ip.src as the message and comparing the hash to the specific cookie.
Part of the challenge I'm facing here is that I seem to only be able to use the entire cookie string like http.cookie and can't use the values of individual cookies.
How can I use the ACL of my application to inform CloudFlare that it should all requests from that user to bypass the WAF?
When you protect an area of your document root using either the server configuration or .htaccess, the server prompts for a username and password when someone requests those files from a browser. If the password matches the one from the authentication provider for that user, the documentation at http://httpd.apache.org/docs/2.2/howto/auth.html says that apache will set environment variables for that user. In my case I'm building a php app, and using phpinfo() I gather that the environment variables set are are REDIRECT_AUTHENTICATE_SAMACCOUNTNAME, AUTHENTICATE_SAMACCOUNTNAME (Using active directory as authentication provider), and REMOTE_USER. I believe this is what prevents the user from being prompted again and again on each subsequent request.
What I don't understand is how apache matches requests from a user with the environment variables set for that user, and also when and how it knows how to clear those variables. I doesn't appear to use cookies, because I cleared all the cookies for the domain in question, and still it doesn't ask me to reauthenticate unless I actually close the browser.
Ultimately I'm going to be working with php to get the userid and to maintain state, but since php is getting the information from the apache information, I'd like to know about that context, and I don't seem to be able to find these details. Thanks in advance.
Look at the http headers your browser is sending. After you have supplied a username and password, your browser will continue sending those details to that site until your browser session ends, or longer if you tell your browser to remember the credentials.
I currently have a landing page setup on my domain.com which already receives traffic.
It will shortly be replaced with an online store. I need to upload this store to my live server in order to get it approved by the Merchant Facility Providers (MFP), and they require it to be accessible from it's final live location on domain.com in order to get approvals. I can't have users access this site until it has met approvals.
To accomplish this I wish to redirect all domain.com traffic to domain.com/holding/ except for MFP visitors.
Ideally this would be restricted by IP address, however MFP say they will need to grant a number of external parties access, and so IP address based access will not be acceptable and I should use passwords.
So my question is, how can I automatically redirect all traffic from domain.com to the holding page domain.com/holding/ unless they have logged in using a password at domain.com/login?
Users visiting the domain.com should not be asked for a password.
Will this be possible using just .htaccess/.htpasswd?
If so, can someone suggest how the logic of how it could work?
It's not possible using just an .htaccess file as all visitors would be presented with an HTTP standard authentication dialog if you enabled it on your domain.com site at the doc_root level.
Without knowing what scripting language you're using? (you've not indicated in the tags, just apache), but you could provide one index page that both acts as a landing page for users/potential-users as well as provide a login (username/password form) for MFP parties (wherever they may come from).
That way, you fulfil both needs without offending or discriminating in any way against any party.
As #nickhar has pointed out, there appears to be no way of doing this using just .htaccess.
My solution was to use a rewrite rule to redirect all requests from domain.com to domain.com/holding unless a specific cookie was set (checked for using RewriteCond %{HTTP_COOKIE}).
I set this cookie in a php script on domain.com/login, which was password protected using .htaccess/.htpasswd.
This is by no means a particularly secure solution, but is adequate for my purposes of keeping the site hidden from general traffic while the approval process is completed.
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