We are using Gigya to authenticate the user which will provide us with user Id and email. Then we pass the user detail to our CRM Web Service which will return the user data from CRM.
We then need to create a session for the user so that we can identify whether the user is logged in or not. If not logged in then redirect to Gigya for login/register etc.
Now, given that we are not using any ASP.NET Membership or similar, I'm thinking how we are going to secure the member pages. One way I can think of is store the user detail in session. Then check if user detail exists in session, if doesn't exist prompt for login.
I'm also thinking whether:
I can use FormsAuthentication.SetAuthCookie or similar to create a asp.net session
Or is there better way to achieve this.
Also, if I use FormsAuthentication.Logout will it clear all my session and cookies even though I'm not using asp.net membership provider?
Goal:
To be able to create a session for the user
Able to authorize user based on user role which we get from CRM.
Able to logout the user on Lout button click.
First, and this is very very very important from a security perspective.
Authentication != Session.
They are different concepts. Second,
NEVER USE SESSION for AUTHENTICATION
see first rule. FormsAuthentication has nothing. Zero. Zilch. Nada. To do with session management. Nor does it have anything to do with Membership or credential verification. All it does is store a cookie that ASP.NET can decode to verify that the user is authenticated or nor. This cookie is set by your application when it has validated the users credentials.
FormsAuthentication.Logout() does not clear sessions, because as I already said, they have nothing to do with each other. You have to clear the session by calling Session.Abandon().
Session is about storing data for a user, and is not secure. Session is volatile, and IIS can discard it whenever it feels like, for any reason, at any time. You cannot depend on Session to be there from request to the next.
Authentication is encrypted, and strictly about proving the user has been authenticated.
Authentication can transcend sessions. It can be good for hours, weeks, months... Your session is only good for the time you are currently there (if IIS doesn't kill it earlier).
Related
We have a log-in form in ASP.Net Webforms. and when user logs in we save the user id to session state.
Session["CurrentUserId"] = user.Id;
So this is how we know a user is logged in.
if(Session["CurrentUserId"] == null) Redirect("Login.aspx");
This is all we use Session for. I am storing session in DynamoDB because we have many load balanced servers. But sometimes DynamoDB gets overloaded or gives errors. So I trying to get rid of session state to avoid these errors and to simplify a login process.
So what alternatives are there? How do modern websites log people in and remember they are logged in, and timeout after x minutes?
Is there a way to use a secure cookie to just do it? And how would you expire it if user doesnt do anything for 20 minutes? It has to work over a collection of web servers.
Storing user ID in session is not necessarily bad but has to be combined with other things in order to secure the site against things like session fixation attack and CSRF (also known as "session riding"). It is also problematic in a web farm if you are using in-proc session state.
In ASP.NET web forms, the standard way to authenticate is to use forms authentication, which places an encrypted cookie ("authentication ticket") on the browser. You may also want to put the user ID somewhere in session and compare it to the authentication ticket in order to ensure they match.
if you using the standard FBA login providers?
You can get user logon ID with this:
Membership.GetUser.ProviderUserKey
And you can get user email with this:
Membership.GetUser.Email
So, the user logon id can be fetched with above.
As for session() being a bottle neck?
Well, it not all that bad - you not "updating" the session() value by doing this, so it certainly does not have to be written back each time (for a post) and also it means that a lock on session() during post backs etc. should not occur.
I would however consider one of the above two approaches, since then session() re-sets or anything else would not matter to get the user ID, or email.
As noted, this much depends on what security and authentication provider you are using here.
My web site is using a session variable to store the login status, like Session["User"],
and checks this session variable in each page, like:
If (Session["User"] == null ) Response.Redirect("loginPage.aspx");
Is the FormAuthentication more secure?
Thanks.
The first thing is that it is more secure then the normal session. There is possibility of session hijacking. You can see following links for more details.
http://msdn.microsoft.com/en-us/library/ms972969.aspx
http://peterwong.net/blog/?p=136
Also sessions can be available even if you are not login. The only thing you need is session Id generated for user.
Following are other advantages.
1) Form authentication can support role based authorization so if you don't want user to access some folder that is specific for only administrator then you can do that every easily with form authentication while with session you need to manually.
2) You can create your login-logout functionality with inbuilt controls of asp.net with membership and forms authentication.
3) Its generates an authentication token so you don't have to check manually every time like in session.
Maintaining critical information in session is not a good idea. Hope this will help you. I high recommend to use form authentication or any latest technologies like ASP.NET Identity for authentication.
We have a FluorineFx / ASP.Net application which uses forms authentication to identify the current user. To use these credentials in FluorineFx, we use FluorineContext.Current.User.Identity. When I log in the first time, the current context neatly reflects the right identity.
When I log out, I perform a FormsAuthentication.SignOut() and a Session.Abandon to invalidate both the user credentials and the session. But when I log in again as another user, FluorineContext.Current.User.Identity contains the credentials of the previous user, while the ASP.Net application has the right user credentials. When I rebuild my application, the FluorineFx credentials are reset to reflect the right credentials again.
Does anyone have an explanation for this, and/or how to fix this?
Because the Session reset works, and the user's identity doesn't, it's not an authentication cookie problem. I still haven't found a good solution for this problem, and decided to store the current user's identity in session. The session variables are encrypted and are updated on each call to make sure the right credentials are passed along.
I am using
FormsAuthentication.SetAuthCookie("username", true );
so that a helpdesk person could impersonate another person's ans go in and see what the account looks like. I as wondering if there is a way my code can determine that this session is running through impersonation (so that I can block a couple of pages and flash a sign saying "You are impersonating this user: username)?
The best thing to do here is make sure the helpdesk users have to be logged in as themselves before they go to the page that allows them to impersonate another user.
At that point, either save a session variable or send a second cookie down to the browser that identifies who they really are and any other info you need to keep up with. I prefer storing this in session variables because it is more secure and you remain in control of the information on the server.
The rest of your code would work mostly like it does now responding as if the user really were the one they impersonate, but any code that needs to test for impersonation can read the session or alt cookie to know if they are impersonating or not.
Our SSO login process uses Forms Authentication against a custom user store in SQL Server.
One of our new security requirements is to only allow an account to have one active session at a time. So any time a user logs in, we will check to see if the login credentials are already active, and preferably prevent the new user from logging in again until the other session ends. Alternatively we could force the other session to end, if that would be easier to implement.
Is there a simple way to do this with Forms Authentication? We've considered a custom approach where we track each session in the database, but it would be a lot of work and we'd probably have to modify all of our applications to detect the session_end, which I'm hoping to avoid. I figure there has to be something in Forms Auth that handles this.
I've seen the MembershipUser.IsOnline() method, which seems ideal, but we're not using a Membership provider.
UPDATE: Just to be clear, I do not need to check whether the current user is logged in, I need to know if somebody else is already logged in using the same account.
Try this:
System.Web.HttpContext.Current.User.Identity.IsAuthenticated
If I understood you correct, you would need to store the last activity state based on the user id.
Membership.IsOnline() is implemented by checking the LastActivityDate property persisted in the membership database.
So somewhere, you would need to track user activity.
You could maybe implement a httpmodule that updates a timestamp for user activity.
If the HttpContext.Current.User property is not null then they are logged in. And Identity.IsAuthenticated is true.