I want to have an SSO for the following sites:
abc.com
def.com
I read this article which has a very basic example on how to setup an SSO with master/slave domain setup. While it was a very good read it leaves some questions unanswered.
abc.com will be the master site that issues the auth cookie.
Say the user is not logged in on any site. If the site is abc.com, all i have to do is check for the auth cookie, no problem. If the user is on def.com, the example in the article redirects to abc.com and returns the cookie content (if any) as a query parameter in yet another redirect. If the cookie has content the cookie will be stored on def.com.
Issues:
Every page reload on def.com triggers 2 redirects if local cookie doesn't exist.
When user logs out, both master and slave cookies have to be deleted and also propagate to any other slave sites.
When the user logs in, I must make sure a cookie is set both on master and slave sites.
I am especially worried about point 1. Is there a way to get around this?
I thought of having the authentication all in ajax, but then i would need a page reload if an auth cookie is returned from abc.com to def.com. Not a very pleasing solution.
Does anyone have a better architecture altogether?
EDIT
Writing this down helped me out to at least to some extent solve the problem. If cookies are set for master + all slave sites at login, point 1 is no longer an issue.
The question is still open for anyone that want's to improve the solution.
Related
I have 2 sites running on one instance of IIS 7.
A.site.com
B.site.com
These sites use forms authentication and there is one form for logging in on site A.
So if i try to access a restricted page on site B with URL
B.site.com/TEST/
i get redirected to
A.site.com/login.aspx?ReturnUrl=%2TEST%2f
I can then enter username and password to authenticate. So far so good.
After authentication I get redirected to
A.site.com/TEST/
instead of
B.site.com/TEST/.
Can anyone tell me how i can get around this problem and make IIS redirect me to the correct page?
Note: the authentication works fine - i can go to the page B.site.com/TEST/ and i am no longer redirected to the login page. So the problem is just redirecting to the wrong site or the value of ReturnUrl should not be a relative path.
A workaround might be to force the user to go back to the last page using JS instead. Not a great answer though i admit. I think this is an IIS bug since the documentation to set up forms authentication with different sub-domains does not mention this problem at all.
EDIT:
A better answer is change the loginUrl to include the domain.
loginUrl="https://A.site.com/Login.aspx?domain=B.site.com"
Then handle the redirect client side
HTTPS is slow to start up, especially on low-bandwidth and high-latency connections, or on low-spec machines. Unfortunately it seems to be the standard method for securing logins used by all major websites.
But a lot of websites we usually visit simply to read information. If we only occasionally want to make a write/update, then waiting to get logged in is an unnecessary time overhead.
The most upsetting example for me is:
Github. I often want to visit a github page just to read a project's overview or view a file. But I must wait for the SSL handshake, even if I don't want to do anything related to my personal account. Github always redirects my browser from HTTP to HTTPS. Why?!
I understand a secure connection is important to authenticate a user account. But when this impacts the user experience of simply viewing public pages, we should try to work out an alternative (and encourage major sites to adopt it).
Here is a possible workaround (1):
Allow users to make HTTP connections to our website, so we can present pages quickly without the need for an SSL handshake.
Allow the login to occur after the page has loaded. Perhaps an Ajax request over HTTPS could authenticate the user, and provide relevant updates to the page. (Is this fundamentally insecure? Edit: Yes, it is not fully secure, see answer below.)
Another alternative might be (2):
Instead of long-lived cookies over HTTPS, use a combination of long-lived one-time-key cookies for persistent login, and short-lived cookies for non-linear browsing, over HTTP. Replace them frequently. (This may be less secure than HTTPS, but more secure than normal long-lived cookie usage over HTTP.)
Do these solutions seem secure enough, or can you suggest something better?
(It might not be a coincidence that I am writing this from somewhere near Indonesia, which is a long way from the USA net!)
Workaround #1 in the question cannot provide full security to the first page, because a man-in-the-middle attack could have injected or modified scripts on the page before the login occurs.
Therefore we should not ask for a username/password on the HTTP page. However, the HTTPS Ajax operation might be able to inform the user that a persistent login session has/can be restored. (A script could then replace all HTTP links on the page with HTTPS links.)
But even if that succeeds, we still should not fully trust any user clicks or <form> POSTs originating from the first page. (Of course, requests to view other pages are fine, but it might be wise to reject updates to settings, password, and finance-related actions.)
This technique could at least be a way to perform the HTTPS setup in the background, without making the user wait for initial content. (StackOverflow uses something like this procedure.) Hopefully the browser will cache the HTTPS connection, or at least the keys, avoiding any delay on subsequent requests.
Here is one alternative I can think of, albeit slightly restrictive:
Allow browsing of public pages over HTTP, but don't perform any user login. This avoids all security concerns.
The 'Login' link would then send us to an HTTPS page, and may be able to recover the user's account automatically from a long-lived HTTPS cookie.
Make an option available "Always log me in through HTTPS", for users who are not bothered by the handshake overhead, and prefer to be logged in at all times. Note that a cookie for this setting would need to be set on the HTTP domain, since it needs to work without the user being logged in!
In reality, we would probably offer the converse: default to the existing prevalent behaviour of redirecting to HTTPS automatically, but provide an opt-out "Do not always switch to HTTPS for login" for those users wishing to avoid the SSL handshake.
But there are still issues with this approach:
Unfortunately cookies are not namespaced to the protocol (http/https). We can mark cookies as "secure" to prevent them ever being sent over HTTP, but some browsers will wipe them entirely if an HTTP request does occur. One way to keep the cookies separate would be to use different domains for unauthenticated and authenticated access to the site. But then we find ourselves violating REST, with two different addresses pointing to essentially the same resource...
Can this be resolved?
This question is an extension to previously answered question
How to give cname forward support to saas software
Sample sites -
client1.mysite.com
client2.mysite.com
...
clientN.mysite.com
Create affinity by say client[1-10].mysite.com to be forwarded to europe.mysite.com => IP address.
Another criteria is it should have little recourse to proxy, firewall and network changes. In essence the solution I am attempting is a Data Dependent Routing (based on URL, Login Information etc.).
However they all mean I have a token based authentication system to authenticate and then redirect the user to a new URL. I am afraid that can be a single point of failure and will need a seperate site from my core app to do such routing. Also its quite some refactoring to existing code. Another concenr is the solution also may not be entirely transparent to the end user as it will be a HTTP Redirect 301.
Keeping in mind that application can be served from Load Balanced Web Servers (IIS) with LB Switch and other Network appliances, I would greatly appreciate if someone can simplify and educate me how this should be designed.
Another resource I have been looking up is -
http://en.wikipedia.org/wiki/DNAME#DNAME_record
You could stick routing information into a cookie, so that the various intermediary systems can then detect that cookie and redirect the user accordingly without there being a single point of failure.
If the user forges a cookie of his own, he might get redirected to a server where he does not belong, but that server would then check whether the cookie is indeed valid, and prevent unauthorized access.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
We recently changed our login to use HTTPS, and we are experiencing issues with the login.
After the login, the user is redirected to an unencrypted (HTTP) page. When it reaches this page, the site checks if the user is logged in. It creates a new session and it appears that the user is not logged in, and thus our user is redirected to the login page. If the user logs in again, it will work.
The cookies are not set as https-only, but it seems like they don't work on http pages.
Does anyone know why this might be happening.
Edit:
I should have mentioned that the page that displays the login is on a different URL. (There is a login page from the machine running the tomcat instance, but the marketing site is on a wordpress install and uses a different domain).
I can't use the HTTP request first method to set the cookie, because the default Internet Explorer settings prevent the session cookie from being saved.
We have this problem with our app. We wanted a similar behavior of logging in via https, then redirecting to an http page.
The issue is that when Tomcat creates the session under https, it creates a secure cookie which can't be read in http. Note that this keeps getting filed as a bug in Tomcat and getting marked as "not a bug".
The solution we ended up is based on the message in this forum
http://forum.java.sun.com/thread.jspa?threadID=197150&start=0
Quoting from the forum thread: "One way to maintain the session in Tomcat, when the session cookie is getting created in SSL mode is to trick the browser by creating the non-secure cookie, when the secure cookie is getting created." This is accomplished via a filter that wraps the request and overrides request.getSession(). It's worked very well for us.
As a side note, redirecting from an https to http page will pop up a warning message in some versions of Internet Explorer "You are about to be redirected to a connection that is not secure." The only way we found to avoid this is to have the redirection be done with a meta refresh tag. Specifically, return a blank page from the original https request with a meta tag that refreshes to an http page. This avoids the warning message at the expense of making the code slightly more convoluted.
(I just noticed some of the advice here is a repeat of an earlier answer -- I apologize, but will post anyways since it is from direct experience).
Edit: I see in your comments you have two domains, which complicates the use of cookies. Can you use a proxy or web server such as Apache to present just one domain to the end users?
When using https tomcat establishes the jsessionid through a secure cookie, which cannot be transmitted through a non-secure connection. So when you fall back to http the session is lost.
The workaround (which I haven't done it myself) seems to be establishing the session through a http request before redirecting to https, and then setting a filter in the HttpRequestWrapper to plug into the nonsecure cookie.
I don't know much about this, but here are a couple of references:
http://forums.sun.com/thread.jspa?threadID=197150
http://tp.its.yale.edu/pipermail/cas/2006-March/002356.html
If you've verified the secure-only flag is off, and that the first cookie is being dropped correctly - I would guess that that there may be a path issue which is preventing the cookie from being presented again.
I'm the IIS admin, not the developer on this site, so the code is opaque to me. I'm stumped, though, for where to look.
Using Windows Forms Authentication, the user is directed to a login page. If their password is expired, they are directed to ChgExpiredPwd.aspx. On our dev and test servers this works. On our production server, the user is redirected to login page again with a "ReturnURL=ChgExpiredPwd.aspx". Not the desired behaviour.
Fiddler says the server is responding with an immediate 302 redirect to the login page. The test server responds with a 200. The IIS properties for the site and for that page have no redirects - all, "The designated file." There's no redirect built into the codebehind so's I can see it. No redirects in the target page, though the redirect is happening server-side, so it has to be in the code somewhere. If I take \bin*.dll from production and put it all on test, it does not reproduce the error.
I'm out of ideas.
Have a look in the web.config file at the root of the site. Forms based authentication is typically configured there and the default behavior is to redirect from a "secure" page to the login to authenticate (if the user has not yet done so), and one of the parameters it passes is the ReturnURL.
This explains it pretty well: http://msdn.microsoft.com/en-us/library/aa480476.aspx