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
Related
I have two websites and i am using the same session object for both the websites.
How can i achieve the same session in two websites.
Regards,
Prasad
You can't. The sites are seperated and as such, the Session data is seperated.
It would be a big security issue if you were able to access Session data from a remote (which this is, even though they are locally hosted) site.
What you are trying to achieve is basically SSO (Single Sign On), in which user is logged in to one site and isn't required to log in to other sister websites.
Either search for SSO and get detailed information on its implementation, or in both of your websites, make a webservice with enable session true.
When you need to check the session["Login"] in one website, call the web method of webservice of other website and get the information and vice versa.
I am trying to share authentication and authorization between different web applications (asp.net application and a MVC4 Application).
I read that you should set the machine key and those values to be the same between the sites. I have done this and the authentication is working properly.
But now in the MVC Application i want to use the Authorize attribute to make sure users can only see what the are supposed to see. This is not working.
I also checked.
When I call User.IsInRole("Admin") from the ASP.Net application(this is where the login is done) the value returned is true, but then when navigating to the MVC application the same call returns false.
It seems that the roles is not being shared across the application, is it possible to get is working or should i Create a custom Authorize Attribute ?
thanks in davance
The more applications you have, the more problematic it is to share the forms cookie. And ultimately, if two applications are on different domains (something.foo.com and somethingelse.bar.com) this won't work as you can't force your browser to submit a cookie to two different domains.
This only works if you have manual control over your forms cookie and issue it for .yourdomain.com top level domain and you have your applications in subdomains (app1.yourdomain.com, app2.yourdomain.com). And this could be a serious restriction.
What you could possibly do is to externalize your authentication, i.e. create a separate web application with the sole goal to authenticate and authorize your users. You pick one of Single Sign-on protocols (WS-Federation, OAuth2, OpenID) and federate your application environment around this authentication provider.
It possibly sounds difficult, especially if this is new to you but if you invest your time, there are only benefits.
I use session objects in my web application which are traced by ASP.NET session cookie internally as we all know. So access to that cookie is essential to have access to session objects. I want my asp.net application work under http:// and http://www or any subdomain (domain is unknown to me at development time).
Can't be done. The session cookie only works for 1 domain and 1 domain only.
You could, however, write your own session management system and maybe accomplish shared session that way. I still don't think you'd be able re-use the cookie because the browser won't even send it in the first place.
After some more thought I've decided that I'm not sure. :) Perhaps if both subdomains map to the same ASP.NET application you could get share session to work. All you'd have to do is set your cookies as such:
<httpCookies domain=".maindomain.com">
If the different subdomians don't map to the same app, I think you'd definitely have to write your own session management.
Clearly, at this point you should take everything I've written with a grain of salt. I'm only leaving my answer up for you to get some ideas and so that people may comment on the correctness of it.
Why don't you leave domain field empty? That way you won't bind your cookies to some specific domain and will be able to play well whatever the domain of your site will be.
Do we need to use out proc sessions while implementing SSO?What will be the limitation of inproc?
which is best way of implementing SSO across domain?
The use of inproc session vs. persisted session has little to do with SSO. The main limitation of inproc sessions is that it won't work in a loadbalanced setup, but again, it has little to do with SSO. The easiest way to implement SSO is to use the Windows Identity Foundation (WIF), which is part of .net framework 4.0 (there is also a version that works with .net 3.5).
Basically you just implement a passive STS. There are several walkthroughs out there.
If both of these applications are using forms authentication then the solution is easy. All you have to do is configure the machineKey on both applications to be identical and set the domain on the forms cookie to be .exampledomain.com for both web.configs.
If you're using a custom authentication scheme built around session variables, you might want to consider configuring both servers to point to the same SQL Session State database. If you go this route, you can modify the GetTempAppID to always return 1 and configure the machineKey on both applications to be identical. Just another suggestion from your friendly sheero. HOI!
inproc sessions will be an issue if your application is running behind the load balancers, so you might want to think about SQL server based sessions, plus you also need to think about if you really need a usual SSO that just keeps you automatically logged in, like if your user has different rights/permission set on different sites then you might want to add some custom code in your SSO login piece, as you have mentioned that you are using ASP.Net 2.0 so i am assuming you might be using the .Net role based profiles for group security and permissions, so you also might want to check if you get your self in a scenario where your logged-in user has different permission set in your different sites. So for me its not just SSO its custom login code for a specific requirement you might want to look into.
I am building a suite of applications using ASP.NET.
Each application can be hosted on separate servers.
All the applications share an integrated database.
All applications require user authentication before use.
I want to build the ability to transfer users from one application to another without having to relogin.
Is there a way to recognize that a user is logged in one application and allow quick navigation to another application on a different server?
Currently I am storing the password hashes in the database; but I wouldn't be opposed to other suggestions if they solve the problem.
Here is what I have done in the past.
Each application must share a forms authentication ticket. To do this the forms authentication cookie name must have the same name, the machineKeys must be the same, and the protection mode must be the same.
This works across domains, but does not work across IPs. What I do to get around this is to serialize the ticket info and store it in the database with the session id as the key. If a user is not authenticated the server will look for the session id in the database and rebuild the FA ticket if found.