I have the one application that can be access from 2 different domains. the application shows data depending on the domain used.
I need the client who logged in domain1 will be also logged in within domain2 access.
Its not so easy as its sound because a cookie is used for the validation and the cookie can not be set from different domains.
Read this post on meta on how stackoverflow make it work: https://meta.stackexchange.com/questions/64260/how-does-sos-new-auto-login-feature-work
Also you can read the Global Network auto-login article.
Related
We're developing a SAAS solution for a big company in which doctors can view patients and make mutations, order products, provide licenses.
This project is for 4 separate companies under one umbrella company. For each company we developed a portal. All portals use the same code but have a strict separated database because the database contains all the patient information.
We're using Sitecore as CMS.
The client decided to use virtual folders instead of subdomains for the production environment. Our staging evironment url is for example: acc-portal1.umbrella.com. For the production environment they would like a URL such as: acc.umbrella.com/portal1. One SSL certificate is being used for all portals and requests.
We're using Membership Provider (forms authentication) for the authentication of users. Users can not log in with the same account in for example portal1 and portal3 because of the usage of separated databases.
Because we're using formsauthentication the ".ASPXAUTH" cookie is being used. Of course the "ASP.NET_SessionId" cookie is used also.
Because the client wants to use virtual folders instead of subdomains, the cookies are shared over all portals. It is possible to set the "path" on the node in web.config but this path is dynamically read by Sitecore and resolved in a pipeline. I did not find a way to override this path after it is being loaded in the web.config. Also I did not find a way to alter the ASP.NET_SessionId cookie path.
My question is: is it a (security) risk to share these cookies over multiple portals (remember, they should be separated completely)? Are there any other problems this setup could cause?
Hope somebody can help!
Yes, there is a huge security risk. What you do is called a multitenant application. You have to take special steps to ensure that cookies and other sensitive data cannot be shared.
My advice would be to store the tenant name (portal1) in the custom data section of the forms authentication cookie. You set the custom data when you issue the forms cookie.
Then, have a custom module or just a handler of the Application_AuthorizeRequest event, where the identity is already established based on the cookie.
In your handler, you decrypt the forms authentication ticket from the cookie, retrieve the user data and compare to the actual url. If there is a match - nothing happens. If there is no match, it means that user is authenticated in one portal but tries to access another. You can gently clear the response and render a message "well, this portal is not meant for you" or just log the user out.
i have an asp.net website http://www.site.com. This web app is also running on http://subdomain1.site.com and http://subdomain2.site.com. Now i want to set authentication cookie in such a way that http://site.comand http://www.site.comshare authentication cookie but it should not be shared by http://subdomain1.site.com. similarly, http://www.domain1.site.com and http://domain1.site.com should share cookie but it should not be shared by http://domain2.site.com or http://www.domain2.site.com. How can i handle this with asp.net?
By default, cookies are associated with a specific domain. For example, if your site is www.contoso.com, the cookies you write are sent to the server when users request any page from that site. (This might not include cookies with a specific path value.) If your site has subdomains—for example, contoso.com, sales.contoso.com, and support.contoso.com—then you can associate cookies with a specific subdomain.
Response.Cookies["domain"].Domain = "support.contoso.com";
Normally a cookie set on contoso.com will be accessed by all subdomain. but if you want to limit sub domain for the cookie you should manually set domain property for each domain you want them to access.
Regards.
I ended up using different cookie names on different domains as described in this article
I have two web application. One is for centralized Image server.
Suppose they are a.com and b.com
b.com is for image server.
and a.com is where my application is hosted.
I have created a handler for images ob b.com which process the request and add watermark and send it back to a.aspx.
I am passing the path of the image (absolute like http://b.com/ImageHandler.ashx?id=imageurl) to the Handler on b.com
Now I am not able to authenticate the request on b.com
Now I am thinking about Handler which is on b.com
should be on a.com
because at a.com I can easily authenticate user.
for this purpose do I need the handler at both a.com and b.com
or is there is any way that I can authenticate the user at b.com.
which has session on a.com.
I can not access the database for each request at b.com because the number of request for the images is very big.
Hope I am able to explain my problem correctly.
You need to first evaluate whether it make sense to have image server under different domain. If its all about sharing the same code among multiple sites then you will be better off by putting you handler under site and sharing the relevant code via class library.
There can be legitimate reasons for having handler on different domain. For example, it might need different level of scaling, it might be resource-hungry and you want to isolate it to different machine (isolating to different app-pool is possible under same domain) or because of some licensing issue (you want to save processor based license cost of some library used by handler).
If there are going to be different domain then you can have them as sub-domains. For example - a.xyz.com and b.xyz.com. In such case, same authentication ticket (issued at parent domain i.e. xyz.com) will suffice for both. See domain property for Forms Authentication Cookie to control this.
You also need to ask if authentication make sense for your image handler. Do you want it to be open or restricted to certain users? If you want only authenticated users and you want to support multiple applications then you are looking at supporting user sets of multiple applications. If it's the same user set (e.g. active directory) then your job will be simpler - have a single authentication provider whose ticket will be trusted by your site and all other applications [Windows Authentication works on similar basis].
If its diverse set of users then it essentially means that for image server, you have multiple authentication providers that you need to trusted. You probably need to look at some Federated Identity system - see one such .NET based implementation discussed here: http://msdn.microsoft.com/en-us/magazine/ff872350.aspx
Maybe this helps:
http://msdn.microsoft.com/en-us/library/eb0zx8fc.aspx
Asp.net forms authentication and multiple domains
If this doesn't work for you you could pass some kind of encrypted token to b.com that b.com can validate to ensure the request is legit.
I have been trying to Google over this topic like crazy. I have this primary domain that has got a couple of subdomains and alied domains. All of these sites share the same set of members that will log-on. Naturally I will have to give them a single sign-on. So I have been looking various forums(including ours) and still have no luck. This is what I have done uptil now.
I have set a common machine key and decryption key of all the websites and also my authentication mode is set to forms. As far as sub domains are concerned, they work fine and a user signed in on the primary gets acknowledged on the sub-domain. The same case unfortunately does not work on domains(and I know cookies cannot be accessed across domains but I have set the machine key and decryption key).
Yes and no. .NET does not support this "out of the box".
If you're willing to force users to a specific domain to sign in, you can then redirect users to that domain/login page. After you have authenticated the user on your primary domain, then you redirect the user back to their original page and post some kind of encryption key to the page that tells the site that the user is authenticated, you then set a cookie for the new domain if you want a persistent authentication cookie.
This is more or less the method used by sites such as Stack Overflow when using Open ID, or for msn when using live id.
I have an application with different sections. Each section is accessed through a domain. Example: www.section1.com, www.section2.com, www.section3.com. I need to preserve the session when the user navigates from one to another URL. The application is the same in IIS. How to accomplish that?
You will need to pass on the session-cookie, and re-set that cookie on the new domain. That will make the session live over several domains (assuming you use the same app).
Example:
Link from section1.com:
<a href="http://www.section2.com/?s=askdjh3k4jh234kjh">
then, OnSessionStart (or OnRequestStart) check for query-parameter s and attach session to it. Meaning, just manually set cookie ASP.NET_SESSIONID to the value you pass on.
This has severe security-implications, so don't allow this unless you know what you're doing. another solution might be to store something into a common backend (database?) and pass around the user with a token that represents the actual session (and set the cookie based on that token), that you generate on a middle-page when navigating away from section1.com -> transferusertonewdomain.aspx -> section2.com/?token=randomTokenThatMatchSessionInDatabase
That would prevent that anyone could hijack a session by jsut knowing the value of the cookie. However, that is possible never the less if you're somewhat familiar with a computer anyway.
If you have multiple domains (and not just subdomains, which are easier), you're going to have more complications doing this than you'd like, because you can't share cookies across different domains.
The usual workaround is to embed a link an image on the other domains that are served by an asp.net page (or HttpHandler if you like). That page should contain a querystring with a unique token and a hashed version of that data appended with some shared secret. Then, that page will set a cookie on the response appropriate to for that domain to associate itself with appropriate data. It will serve typically a 1x1 transparent image as the response. Usually you only want to do this upon login to one of the sites.
Unless you do some customizations, session is specific to an application regardless of session mode you are using. Here's an article that talks about how to customize SQL session so that you can use session across multiple applications.
You should start by change the sessionState from being "InProc" to either StateServer or SqlServer, ensure that the MachineKeys are identical across all sites (domains and servers), and then set up the relevant backend systems to capture the state information.
More information can be found on:
Session-State Modes
ASP.NET State Management Overview
You could use a cookie to pass it, still researching to find out how. I will repost.
** EDIT
There is another Stack Overflow question, see if it helps, 315132
It basically asks
I need to share SSO information
between two different domains with a
cookie, can this be done in PHP and
how?
the answer given was
On both domains, place an image or
other web element that is pulled from
the other domain. Use the URL to
notify the other domain that user X is
on domain A, and let domain B
associate that user ID with that user
on their system.
It's a little complex to carry out
correctly, but if you think it through
it'll work out very well.
Vinko points out in a comment
(thanks!) that I shouldn't take it for
granted that you understand the
security risks involved. If this
information is of any value to anyone,
then you should make sure you use
proper encryption, authentication, etc
to avoid releasing sensitive
information and to avoid various
attacks (replay, man in the middle,
etc). This shouldn't be too onerous
since you control both websites and
you can select a secure secret key for
both, since the communication is only
going between the two servers via this
special URL. Keep it in mind though.
The user is Adam Davis.