I have two website consider it as website1 and website2.
In website2 there is a login page .When a user click on the login button it will call a HTTPhandler in website1 to authenticate user.On successful authentication user information will be stored in a Session variable from handler.
Then it will redirect to a page page1.aspx in website1.But the previously set session is not available in the page1.aspx .What will be the issue?
I checked the session id in first request(when calling handler in website 1 from webiste 2) and Second request( redirecting to the page1.aspx from the handler) the session id is different.
How can i retain the session data?
You need to store session data in another process shared to both web site.
You can do it intwo different ways:
Configure an SQL server
Configure SessionState service, a Windows service used to share informations.
In both cases you have to change both web.config files to support the new session mode.
I.e. to use SQL:
Prepare a database (from command prompt):
cd \Windows\Microsoft.NET\Framework\v4.0.30319
aspnet_regsql.exe -ssadd -E -S localhost\sqlexpress
Modify web config as following:
<sessionState mode="SQLServer"
sqlConnectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;Initial Catalog=Test" allowCustomSqlDatabase="true"/>
You don't need to change your code.
Correct me if I an wrong, AFAIK different domains cannot share a single session. One way to handle this is to carry the data to the other site through cookie [encrypt the values for security], then copy this cookie value to the session in the other site receiving it and destroy the cookie.
And if the sites are in different servers you need to handle the "sticky session" so that servers share the session.
This situation sounds kind of similar to one I have experienced and worked on before, where one web application acts as the login page while another is the actual app where all your work is done. I can describe what I did in the hope that you find it useful.
Like you I had one web app which had the login page (so in your example this would be website2). When the login form submitted I then redirect to a fake Login.aspx page in website1 - this is where we differ I think as I'm not sure of your specific reason for using a HttpHandler.
In my case the website2 Login.aspx page is actually just the way into the web application; it has no markup, just code-behind which will authenticate the user, perform setup (e.g. set session variables) and then redirect to another page such as Homepage.aspx. This particular scenario has worked for me, so maybe your problem revolves around the use of a HttpHandler though I would not be able to tell you why.
In order to retain the same session date across two different servers running ASP.NET web applications you must configure your session state to be managed out of process. This means the actual session state data variables will be stored outside of worker process and in another process that is able to make the session data available to other machines.
To achieve this you can configure your application to use SQL Server to store session state and make it available to multiple servers in your farm. The TechNet article Configure a SQL Server to Maintain Session State (IIS 7) provides details on hor this is done in IIS 7.
If you are using IIS 6 then the steps to configure are somewhat different and I can provide further details on this if needed.
In order for this to work you do need to ensure that both servers are running applications within the same domain, e.g. myapp.com, otherwise the ASP.Net session cookie will not be passed between the two servers. ASP.Net uses the cookie to lookup the session state stored in SQL Server and will therefore not find any matching session if the cookie is not passed on requests between the two servers.
i think IRequiresSessionState will not help because context is different.
once we had the same problem but that was passing asp session varibles to .net. How ever you can do it here also.
on both website create a page setsession.aspx
now if you are on page say web1/page5.aspx and want to go to web2/page3.aspx
you redirect to web1/setsession.aspx?togo1=web2/page3.aspx
in both setsession.aspx logic in to extract sessiondata and place them in querystring
so the web1/setsession will redirect to web2/setsession.aspx?sess1=value1&sess2=value2&togo=page3.aspx
web2/setsession.aspx will check for togo querystring and if found will extract all querystring name and value will set them in session and will then redirect to togo value.
you need to differentiate togo1 and togo carefully.
Session sharing between websites is going to require hand-coding. You could hack the asp.net framework to get this working, but I feel that this is not a clean way of achieving what you set out.
If user authentication is all you are doing from website, is it possible to use alternative? Single Sign On mechanisms will help you out here.
Something like SAMLSSO could help you in this case.
You have two websites which are hosted on different servers, it means you have two different processes running on separate machines, so sessions will be definitely different. Same session can't be shared across processes because by default asp.net support in-memory session.
Here you would need to think about storing sessions information which can be shared between two processes (i.e. out of process). Ideal way to store sessions information in databases. For this you can consider Stefano Altieri code sample above.
I don't think you really want to share session information between two websites at all. From what I can gather from comments, what you're really trying to do is have a user authenticate in one website (give you a username and password which are validated) and then have that "logged in" state transferred to another website which doesn't handle authentication for itself.
What you are describing is the Delegated Authentication model.
In this model, your application hands-off authentication to other systems which it trusts to provide information about users.
There are two well-known protocols which provide this mechanism:
OpenID
This is intended to facilitate users logging in with their own identity providers (Google, Facebook, Microsoft Account). It's a very good choice if you're running a public-facing website, as most users will already have an account they can log in with.
WS-Federation
This is intended to facilitate users logging in with identity providers which are managed by known trusted parties, such as partner organisations.
From version 4.5, the .NET Framework has built-in support for WS-Federation via the Windows Identity Foundation component (and is also available for earlier versions as a separate download). This automates the task of delegating your authentication to an Identity Provider.
It also provides components for you to write your own Identity Provider, should you want to create your own, but you shouldn't have to; you can find various existing implementations to perform this job for you.
The problem you're trying to solve is a very difficult one, especially trying to make it secure enough to be reliable. The good news is that smarter people than you or I have spent years working out very clever ways of doing this. You should use what they have done and not try to cobble together something out of Session state.
In the long-run it's best to let the smarter men do the hard work for you.
Related
I have an application that uses APS.NET as the middle tier. One of the features for administrators is to allow them to popup another browser window logged in as a non-admin user, so they can provide support.
I use a javascript function "openWindowWithPost." The application takes credentials from a DB and forces a login so the support staff does not need to know the user credentials. Unfortunately when it does that the original session is reused and hence all of their application variables are shared, causing havoc with the original Admin login.
What I would like the ability to do is to force a second browser window to popup and when it talks to IIS have it create a new session and keep the original one active. Is this possible? If so where can I find how to do this?
From your post, it looks like you are using the Session object in ASP.Net to store data.
By default the Session ID is stored by the browser in a cookie. See MSDN
for a description of how it works. You could setup your application to use query strings to store the session id, but that is really old fashion and can become messy and hard to deal with.
Your best bet is to find a solution at the browser level. For example, Firefox has an extension called Multifox that would do what you want. Other browsers have similar extensions.
I have four systems running on the same server. I want to let the users to log in once for all the systems. I made one user-management system to create users and edit them.
I tried to save in the session but it didn't help.
Any suggestions? I am working on asp.net.
There are two approaches.
Most resolve around the login happening at a central site, which then returns with an identity information field (login token) that the target site uses to retreive the user.
When you go to another site, the site redirects you shortly to the central site and if you are logged in (persistent cookie) you get back the identity of you.
Alternatively you can do a lot with referrers and playing around.
YOu want to do some research on the internet - what you loo kfo is "Single Sign On".
http://www.codeproject.com/Articles/27576/Single-Sign-on-in-ASP-NET-and-Other-Platforms
has some technical discussions.
Across complete separate websites (domains) you can read up on
http://aspalliance.com/1513_Cross_Site_Authentication_and_Data_Transfer
howw to do it - obviously shared cookies will not work there.
The best way to do this is with Federated Security. If you were using Windows Authentication then you could use Active Directory Federation Services (ADFS). In this model, users reference a Web application and the principal on the current thread is checked. If the value is null then information stored in the web.config will redirect the request to a login page automatically. This is assuming there is no a Windows security context, otherwise the user can be automatically logged in.
After the user is successfully logged into the environment, the principal on the thread is populated and a set of claims are issued that are specific for that user. Since the claims are associated with the principal and not with a specific application, they can be used across the board by any claims aware application.
If you aren't using Windows Authentication, you can still accomplish the same thing, the only problem is that you cannot use ADFS. Instead, you'll have to implement your own Identity Provider to replace ADFS. The .NET Framework does provide base classes and interfaces to help you accomplish that.
I would suggest looking into ActiveDirectory or any LDAP server for single signon to access all applications. If you cannot (or do not wish to) use LDAP, you could implement similar functionality (but with more development work/time spent) with any memory/disk store. If this is not possible, please share why as it might be useful to others.
Hope this helps.
My asp.net session objects are storing in SQL server.I am storing an ID in session. If client open another browser and storing different ID in session. I need to notify client is “are you sure you want both ID’s open?” in same based user logged user.
Application runs on logged in user (not anonymous)
How can we check this in asp.net?
Session is not linked to an authenticated user, and there is no way of accessing an other connection's Session without knowing its SessionID.
Usually this kind of problem can be solved using cache instead of session state. With cache you can create your own user-based keys to store data. Depending on whether you are planning to just run your web app on one server or in a web farm environment, you can either use asp.net in-process cache or one of numerous distributed cache solutions (like memcached which I'm using in my web projects with great success).
There are a couple ways to go about this:
Option #1, in your user table, add a value called "session id"
When a user logs in, check to see what their last session id was. Then test to see if it's still a valid session. If it is, ask them what they want to do. Store the latest session id in that table after each log in.
However, I'd go with option #2: Don't do this. If the user wants to open multiple browser windows to access your application then let them. There's probably a pretty good reason for it. Most (as in nearly all) users have no idea what "session state" even means and they really have no desire to know. All they care about is getting their job done.
I was wondering if anybody could give advice on a secure way to implement a global login. I have an admin page that accesses active directory admin groups after typing in your username and password.
current logged in account (on computer) does not matter
user in web browser goes to web app, redirects to global login page with query string of app name
types user name and password of an account in AD (not necessarily current computers logged in user)
authenticates (looks up user, pass etc and authentication is valid)
redirects back to original web app.
Once redirection happens, how do I securely tell the original web app that this user is ok until the original web session dies?
The way I'm thinking of implementing it:
My original thought was to pass the session ID of original app to the login page as well as the app
name. Store that session in a DB once authentication is checked. Master page of the other app validates on page load that the session ID matches. On session close, remove current session ID from DB.
You cannot depend on sessionID accurately in some cases. SessionID only becomes a constant value after a (any) page makes a request for a session variable, if you dont have Session_Start not defined in global.asax. If you log the user in and the default page does not access session, you will end up with a different session id for the subsequent requests until a request to session is made. Usually it is always constant as there is a default empty session_start event in global.asax.
But similar to your model, you could generate a GUID (or make sure you access session on login/authentication) and store it in the user table with an expiration. Your web sites can check this key and if currently valid, auto sign the user in.
You also cannot depend on session_end event since there is no real accurate way of detecting it (eg: user closing browser). So, you should store this ID with an expiration time along with it, preferably the same as session timeout. Just like session, you will need to extend this, something like a sliding expiration. This way, this id will be expired after a period of inactivity.
also, this Claims-Based Single Sign-On for the Web may be of interest to you.
What you're describing sounds like it would be better implemented using Windows Identity Foundation and Active Directory Federation Services 2.0. I don't know the extent of all your requirements, but it might be valuable to check out what these will give you out of the box.
You could use a cookie. If you pass the name of the application to the login page, you can set that application name to the PATH property of the formsauthentication cookie. By setting the PATH property, you're effectively limiting the readability of the cookie to the pages within that path. Because it's a common login interface, this may require some code being done perhaps in a common page base class that handles the parsing of the cookie information.
You can share authentication tokens between .NET applications, even between .NET CLR's if you want to. I think this will give you the single sign on you're looking for.
At a high level you need to share a machine key between the applications. You can generate the machine key using the key generator app code example found on this link, and providing you then reference the same key in each application the sign on can be shared:
http://msdn.microsoft.com/en-us/library/ms998288.aspx
There are some consideration when looking at things across domains or accross machines/web farms etc, but if all apps are on the same box it's not too hard.
The harder side of things is sharing things like session state which I don't believe can be done accross app pools. (I ended up recreating the session object on the new app manually last time I did it :( but that was between 1.1 and 2.0 apps )
EDIT: I did a rough write up of it last year and was using it as a test for a demo article on my site, might be worth a read through if you want things broken down a bit more (Ignore the unfinished site!):
http://www.dougmcdonald.co.uk/test/html5/v5/articles/2010/05/10/Sharing-forms-authentication-between-applications/
I have been tasked with developing a single Login and Dashboard page that user can login too, the user will then be shown all the systems (we developed) that they have access based to based on some roles stored in our databases.
If they logged in we would like that "User Session" (not sure of correct terminology) to be carried to which ever system they are redirected too.
To illustrate a very rough overview of what I want to achieve:
alt text http://www.pcbg.co.za/attachment.php?attachmentid=12165&d=1268903524
Is there a way that a user can login in one site, and then carry over that login to the other sites?
Help, Advice, Link will be much appreciated.
Sorry I am not experienced at ASP.net but have a good understanding of Silverlight, C#, WPF.
Thanks in advance.
You can use the concepts of single-sign on. You can manage your session data as out-proc, i.e. in a SQL server or a State server. Here are couple of links which will give you some pointers:
ASP Allaince
MSDN
Edit: Alo look at this question in SO:
One method that I would use is that you implement your own authentication system - almost like the ASP.NET 1.x days. However, the trick is that you establish a cookie for each domain (host part of the URL) with an authentication cookie.
If all of those systems are running on the same server, I am sure you will be able to use all the FormsAuthentication methods and the Membership API. If they are not [edit: hosted on the same server], then ensure that they configured to encrypt the authentication cookies with the same keys. Implementation of this bit will be by what mileage you need to do...
One thing to notice is that you may also establish only one cookie is sent to the browser but shared by all the applications. Imagine that you have the following URL's:
dashboard.com
myapp1.dashboard.com
myapp2.dashboard.com
myapp3.dashboard.com
Setting a single cookie to the domain "dashboard.com" will send and share the same cookie to all the other domains.
The shared session states as described by the other posters will not work. The way session variables work on the server is that an unique key is generated on the server for your data storage (whatever the medium is: in proc, out of proc, SQL server). That unique key is stored in a cookie where it is sent to your browser as the host part.
I hope that gives you some insight on how to go about tackling the single sign in solution that you are making.
One way would be to use the session state service that ASP.NET provides. Basically once the user logs in, that session could be stored on a separate process (and not be a part of aspnet_wp). All your applications would need to be modified to go to that machine to fetch user authentication status. Search Google/MSDN for Session Management techniques.