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.
Related
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
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'm writing an internal web application right now (with ASP.Net Web Forms), and it presents an odd problem. I have to be able to impersonate the currently logged in windows user, and execute a command based on their Windows Authentication to log in.. AND ... if they don't have Windows Authentication set up in the application I have to use to log them in, I have to be able to accept a user name and password. I also have to write the application in .Net 4.0, and secure it as much as possible. I got this to work by NOT utilizing Windows Authentication or Forms Authentication in the web.config, and instead setting session variables to guard against user accessing pages in the web app other that the log in. I did this by creating an oddly name session variable with a value based on their user name (windows auth or not), and then a secret session variable. The secret variable is in the web.config as a 256bit encrypted string, in which I decrypt, and set as the session secret. In order for the page to load, the first session variable can't be blank, and the second variable has to equal the decrypted key value... if the variables don't pass inspection, it redirects them to the login page. I set this up on every page, generic handler, and webservice method in the web app. I make the session timeout after a few minutes of no activity, and on log out, I set all session variables to nothing, and expire all cookies. (I also disable all cache).
My question is... Does this offer comparable security to that of Forms authentication? I have always used Forms authentication, but can't use it here. If I did, the users would have to reconfigure settings in IIS and in he web.config to toggle login procedures (From my knowledge, you can't use both Forms authentication, and windows authentication to manage the security of your pages and other web resources). With the method described above, I can accomplish the best of both worlds, but am curious about the security of my methods. Is there anything else I can implement here to assure the utmost security other that using forms authentication? Is it possible to accomplish the same level of security of Forms authentication without using it?
Thank you for any insight in advance!
Does this offer comparable security to that of Forms authentication?
No
The first rule when it comes to security is don't reinvent the wheel unless you absolutely have to. Any home baked solution you come up with has the potential to be as secure as a provided one like Windows or Forms Authentication. The problem is that home-grown solutions rarely reach that potential. They may test okay, but subtle bugs can remain. You don't want to find out a year later that you were hacked six months ago. Existing solutions have already been tested and used in millions of applications, whereas yours will be used in one application and tested by a handful of people at most.
A quick search suggests that it is possible to implement both Windows and Forms Authentication in the same application, so I'd pursue it further.
Mixing Forms and Windows Security in ASP.NET
when to use
windows authentication, form authentication, passport authentication, none?
I don't find on internet any relevant matter on it, although all say how to use these authentication.
But no one says which one is superior and when to use one.
Please elaborate a little on it.
Also i want to know benefit of one over another, and what is that authentication i did by now by creating table with user id and password and match the user id and password with the data table. If that can be done easily what is the need of these authentication.
It depends on the project and what you want to achieve. If you were developing an Intranet for a company obviously only to be accessed from internal computers then windows authentication would be the choice.
If you want people to register and wish to access as much information as possible then use forms authentication to get the data you require and store it alongside membership.
If you want people to come and go from your site with ease with as little steps as possible for registration, then use Passport.
Hope this helps :)
Windows authentication is generally for companies where people do something locally and server checks if the computer that is trying to do something is valid.Example: Company that accepts some requests and people working there do something with them.
Forms authentication is for whole web where you want people to access the content regardless from PC/other device? they are using.Example: Website like this.
Windows Authentication is generally used for Active Directory-enabled networks, such as Intranet sites etc. where the user's Windows credentials double as a login to the web app.
Forms Authentication allows you to use the .NET Membership/Role/Login features and control a more in-depth user database.
I've never come across a good reason to use Passport Authentication, but it's a proprietry MS single-signon style authentication method.
We have several ASP.NET applications deployed to a few servers. Is there a standard way to reuse session data or some other method to not require users to log in to the next application when moving from application to application if they've already authenticated? I'm hoping there's a best practices way of doing this that you guys know about. I feel like there should be something easy that I'm missing.
Thanks.
Edit: To be be more clear, the main info in the session that I'd like to pass is the authenticated userid, but possibly some other session variables as well.
you could implement a single-signon strategy for your applications.
http://aspalliance.com/1545_Understanding_Single_SignOn_in_ASPNET_20.all
http://blah.winsmarts.com/2006/05/19/aspnet-20-implementing-single-sign-on-sso-with-membership-api.aspx
http://johndyer.name/post/2005/12/Single-SignOn-with-ASPNET-Membership-and-WebServices.aspx
http://msdn.microsoft.com/en-us/library/ms972971.aspx
Single Sign On (SSO)
http://msdn.microsoft.com/en-us/library/ms972971.aspx
For the session check this: http://www.codeproject.com/KB/aspnet/Sharing_session_state.aspx
Complement with this so the cookie is shared: http://mgrzyb.blogspot.com/2007/12/aspnet-and-subdomains.html
It's not clear from you question if you're just concerned about logons, or if you really need to share session data between applications.
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.
Sharing a sign-on between applications (covered above) is quite a different ball game to sharing ASP.NET Sessions between applications.
Why do you want to share Sessions between applications?
ASP.NET Session is a metaphor for a user's current interaction with one ASP.NET application. It exists in ASP.NET to give us a place to store temporary state data between the various page requests that a user makes while using your application.
If your applications are very closely related, e.g. the user uses both at the same time, or almost the same time, you could consider merging them into a single ASP.NET application.
If your applications are not that closely related, perhaps they should be sharing the same database as a means to exchange data, or using an API e.g. based on Web Services to exchange information.
Hope that helps.