I'm working on a multi-tenant ASP.NET MVC application.
So far we have been using HttpContext to store a few objects for the request (technically partitioned by tenant).
However, we will need to use TempData (uses Session) and set authentication cookies.
Our spec:
A tenant can have multiple urls (tenant1.myapp.com or mycustomdomain.com)
Authentication cookies should NOT be shared by tenants
Ideally, a tenant's authentication cookie should be shared by any one of their urls
Is Session domain aware? It seems to be.
Can I set multiple domains on an authentication cookie?
Advice on anything else that may catch me out would be appreciated. Really I just need to understand what needs to be partitioned for each tenant (up to now I've partitioned the file system, database and cache per tenant).
Thanks
Ben
Is Session domain aware?
By default Session is tracked by cookies and because cookies are restricted to the same domain the session is not only domain aware but also application-aware meaning that if you have two applications on the same domain they won't share session.
Can I set multiple domains on an authentication cookie?
No. Cookies cannot be shared between domains. But contrary to sessions you can share them among multiple applications on the same domain (by setting the domain attribute to the top level domain in the <forms> tag in web.config). This is what allows to achieve single sign on between applications on the same domain. If you wanted to achieve single sign on between applications on different domains you will need different approach.
you may want to look into Session Partitioning.
<configuration>
<system.web>
<sessionState
mode="StateServer"
partitionResolverType=
"IndustryStrengthSessionState.PartitionResolver" />
</system.web>
</configuration>
But I don't believe you can share sessions across domains out of the box. You will likely need to add custom session synchronization, where each domains session is linked by a custom algorithm to the same user/tenant etc.
Related
I have a working shared session setup. However, some of my users want to navigate to the servers using their internal IPs rather than their hostnames. This breaks my shared session due to my <httpCookies domain=".abc.def.com" /> web.config element.
The element means a users' session is shared when they navigate from old.abc.def.com/index to new.abc.def.com/index. However, if my users want to navigate from 192.168.1.2/index to 192.168.1.3/index, the session is lost.
Is there a way to share the session across IPs? I haven't read anything that gives me hope for this.
I'm afraid that's impossible due to browsers security restrictions. According to RFC specification setting cookie from one domain to another is validated against these domain matching rules - https://www.rfc-editor.org/rfc/rfc6265#section-5.1.3
Can ASP.NET applications in a common application pool share session information if they are in separate threads in a single worker process? One of my applications is having issues related to not having any of the session information it needs from the other application, but I used Trace.axd to confirm that requests to each application are using the same session identifier.
I resolved the issues we were experiencing by making our applications "cookieless".
I updated the web.config file for the applications as follows:
<!--sessionState mode="InProc" cookieless="false" timeout="30" /-->
<sessionState mode="InProc" cookieless="true" timeout="30" />
If anyone can explain why this works, I would appreciate the education.
Thank you to all who offered suggestions.
ASP.NET session is scoped "within" application if using out-of-the-box session providers, so each application will have its own session even if the session id/key value appears to be the same. But since the requests to each application are using the same session identifier value, you appear to be well set to implement a custom SessionStateStoreProvider that can store/retrieve data using this identifier across both applications.
You could also have a look at Sharing sessions across applications using the ASP.NET Session State Service, but since this approach involves modifying the workings of the stock SQL session store provider, you'd risk spillover effects on other sites/applications.
I thik it could be helpfull Sharing Aspnet Session across different domains there's no other way.
you cannot share a session between different domain.
there's another solution that could be pass all data via querystring to the other domain so it can rebuild the right session values.
Personally i will invite you to use encrypted value to be sure that are not visibile if you will choose GET option.
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.
Is it possible to share Session state between web applications on separate servers? One of the web sites is using session state to maintain user credentials/info session state, the other is using forms authentication to maintain this information. Without modifications to the website using session storage, is it possible for the website using forms auth to read/access the session state on the other server? If not, which I assume is the answer, would it be possible if they ran on the same server? (i.e. the same app pool)?
Note: Both applications are under the same domain name (one of them will be a sub-domain)
As a note, the reason this is being asked is because a client is requesting a "single sign-on" approach between two websites. We're using forms authentication and the other site (which we cannot modify at this moment) is maintaining credentials/logon information in session
ASP.NET 4
IIS 7.5
Assuming the latter, you could try something like this:
first, make sure all the appliations are running in the same domain. If not, all bets are off. I don't know if there's a simple way to configure the domain property of the session cookie yet, so you may have to do it yourself, by setting the cookie domain property to the domain:
Response.Cookies["ASP.NET_SessionId"].Domain = ".mydomain.com";
you'll need to make sure that each application is configured to use either a common state server, or a db-backed session.
please follow the link : How to share session state across subdomains
We are launching a new web site using a sub-domain and need to ensure that users logging in to the original (main domain) site, are also authenticated in the new site.
I believe I need to ensure all related web.config settings (forms authentication, cookie names etc) are the same in both applications and also manually set the machineKey validationKey/decryptionKeys (again, the same in both apps).
My question is, if I now manually set theses keys in my main app, will it break the existing logins?
We are using the "hashed" format for passwords.
Depends what you mean by "break". If you modify the machineKeys/encryptiong keys people might have to log back in but the login functionality will continue to work as before.
You also need to make sure that the domain for your cookie are set to domain.com in both places (without the www) or the authentication cookies will not be shard correctly between the sites.