I want to know how can I force a user to log in the the application again if the page is being opened in new tab or new browser.
Edit:-
My apologies I misunderstood the requirement.
I am authenticating the user in my log-in page but not anywhere else. So what is happening because of that, even if i log out of application and type url say bla.com/apple I can access my application.
I figured to prevent this from happening, I have to write a base controller that checks for the right user. Am I moving in the right direction.
Thanks
Addressing the edit -
Authentication can be handled per controller or on individual actions. Simple place the [Authorize] attribute appropriately. This assumes however that somewhere an authentication token is being set. [Authorize] checks against the HttpContext's current User (an IPrincipal).
You mentioned above that you're just validating against a local username and password, in one place, so I'm guessing that no token (session, cookie) are being set?
You have a few options here to get that token stored and persisted across requests:
ASP.Net integrated membership provider (Intro)
A custom MembershipProvider (Example)
Full-on custom flow. (Example)
Each has ups and downs and depends on how exactly you want to handle on-boarding your users. It's hard to answer more specifically because it can be a very large topic (and a very broad question).
Here's the official pages for MVC security.
Related
This is a follow-up question to Is Forms Authentication as described in the Nancy docs susceptible to session hijacking?
I understand now how Nancy Form Authentication works and also the idea behind it, thanks to Steven Robbins' answer.
However, for my application that approach is not sufficient. It must not be possible to gain eternal access for an attacker if he manages to steal the auth cookie once. Thus, I'm currently investigating possibilities to switch to a session-based approach to authentication, so I can invalidate sessions when the user logs out and also after a fixed amount of time.
Nice thing about Nancy, such things can be customized!
My question is, does it make sense to reuse Nancy.FormsAuthentication for that purpose? One solution I have in mind is making the user identifier only temporarily valid. That way I would delete the GUID identifier from the user database when the user logs out, and create a new one everytime a user logs in.
I'm asking because the docs state:
It is also important to know that the identifier should be treated as
permanent for the user that it was generated for and will be reused
across requests and application sessions.
Are there any unwanted side-effects when I ignore that and make the identifier non-permanent?
Yes and no.
If you change it each time the user logs in then you are effectively logging the user out.
You could create a Session / Identity table which allows the same user to login multiple times (assuming that the browser is different) which would allow you to manage the timeout / extending the timeout on each authentication.
That would require no changes to the Forms Auth, you would simply change the IUserMapper to authenticate against your Session / Identity table rather than the user directly.
(hope all that makes sense)
Currently I have a custom form login page in Spring Security 3 that sends its form data to the correct authentication url.
However now I need to extend the process to support security questions after logging in but before hitting the rest of the site.
I have a few options from reading the documentation, but I'm confused as to the correct option to choose.
Option 1: Keep the current login system and set a special role that only lets the user access the security questions page. If they pass through the security questions process successfully, add their correct roles into the security context.
Option 2: Subclass AbstractAuthenticationProcessingFilter and do security questions as a part of the login process. This seems more spring-like but I'm stuck on how to support the multiple pages for the questions with breaking the rest of the authentication framework.
What about this approach:
When a user submits her username/password, save them into her session.
Redirect her to your questions.
When she is finished answering your questions, see if you want to let her login.
3.1. If yes, POST her saved credentials so that they could be caught and processed by Spring Security filter chain.
3.2. If no, take her back to the login page. (Or whatever you want to do in this case.)
I ended up using Option 1. #craftsman's answer doesn't fit since the questions are specific per user. Its actually worked out really well.
I am building an ASP.NET MVC3 app using Forms Authentication and I'd like to log out all existing sessions for a user when that user logs in. I'm trying to prevent multiple people at different workstations from logging in and working under the same account.
Is there a standard way of handling this? Logging out the existing session is easy, but I haven't come across a way to check for other sessions by the same account and log them out.
I have a few ideas on how to hack this, but I'm curious if there's an established method for this using IIS or the FormsAuthentication API.
Because of the statelessness of the web, you can't "log out" a session until they make their next request (for instance, session might be maintained in a cookie, which can't be written on the client outside of the context of a request-response interaction).
There is still a solution, which assumes you are using session state, and preferably you have a common base controller for all of your controllers requiring "Authentication".
Upon successful login, generate a token (a guid perhaps) and store that with the session. Also write this to a application-wide store (database or application context for instance) keyed by the userid.
In the Base Controller (or otherwise you'd have to create an action filter) check the token in session against the token registered for the userid in the application-wide store. If they don't match, log out the user using the standard SignOut() call.
You could use the Membership.IsOnline property which is based on LastActivityDate:
A user is considered online if the
current date and time minus the
UserIsOnlineTimeWindow property value
is earlier than the LastActivityDate
for the user.
I believe for a typical MVC web application the router / dispatcher routine is used to decide which controller is loaded based primarily on the area requested in the url by the user.
However, in addition to checking the url query string, I also like to use the dispatcher to check whether the user is currently logged in or not to decide which controller is loaded. For example if they are logged in and request the login page, the dispatcher would load their account instead.
But is this a fairly non-standard design? Would it violate MVC in any way? I only ask as the examples I've read through this weekend have had no major calculations performed before the dispatcher routine, and commonly check whether the user is logged in or not per controller, and then redirect where necessary.
But to me it seems odd to redirect a logged in user from the login area to account area if you could just load the account controller in the first place?
I hope I've explained my consternation well enough, but could anyone offer some details on how they handle logged in users, and similar session data?
The current MVC framework that I'm using has pre dispatched and post dispatched features. I normally place the login checking in the predispatch process rather than directly putting it in the dispatcher. Also, an authentication class may do the job for you.
This seems to be fair requirement, and can be achieved using a intercepting filter. The request header can be inspected and flagged as an attempt to login, or mark as a malicious attempt. Alternatively the dispatcher can delegate this to a different controller which can do the same and redirect the request appropriately. MVC is all about segregation of intelligence in the application. This case falls under sanity check (technical requriement than a business requirement).
Are there Custom ASP.NET Membership Providers for sale with added security?
For example, the ability to have multiple Questions/Answers that are randomly presented for Password reset, set number of login attempts, force password resets every 30 days, prevent duplicate passwords for new password for a certain period of time, etc
I've recently updated my custom provider with some of your requested features. Unfortunately it's not exactly for sale, but I did want to tell you that it wouldn't be terribly difficult to do on your own.
The multiple question/answer feature and the force reset (password expiration) actually can be implemented using any provider because they're not directly enforced by the provider. To enable Password Resets you could simply define a constant in your appSettings, i.e. "PasswordLifetimeInDays". Then in your Login page simply override the Authenticate method and inspected the LastPasswordChange property of the MembershipUser. If their password has expired then redirect them to a ChangePassword page, otherwise log them in. Check out this article for a walk through of implementing this feature.
The pre-generated question scenario is also something that doesn't really fit in as provider functionality. Although, a third party solution could contain this mechanism in a separate API I suppose.
The SqlMembershipProvider already provides a way to set the number of login attempts via the MaxInvalidPasswordAttempts attribute.
Really, the duplicate passwords functionality is the only piece that truly belongs in the provider implementation as it requires an additional table to track the password history.
Let me know if you ever decide to implement this stuff on your own and I could offer some more guidance.