This is one MVC application and we are using FormsAuthentication
FormsAuthentication.SetAuthCookie(userName, model.RememberMe);
We would to maintain log of the users who are accessing the system (For analysis how often one user is accessing the system)
We can catch it while authorizing them through the login page. But as application provides “Remember Me” option which remember the password so in-case one user press it today and access the system tomorrow again we won’t capture.
There are some alternatives which we are thinking (Except removing remember me) but I wonder is there any best way for it?
We just to need to capture day wise data. Like User A last time access on date?
Best Regards.
A better place to log authenticate requests is either in a Httpmodule or ActionFilter in ASP.Net MVC. You can get User information from the HttpContent.User and also his cookies information from HttpContext.Request.Cookies
In the following example, even though the user checks the remember me, this HttpModule will invoke and checks for HttpContext. This is a good place to keep track of returning users - ASP.Net HttpModule for Security
The similar feature can be achieved using ActionFilters which is specific to MVC - Authentication using ActionFilter
Related
ASP.NET MVC 4.7.2. I am getting some users' information from Azure AD and store that in session so I do not have to call back again until session is live.
But the problem is when the user close the window or signs out, the session also ends, however user can still sign in without authentication process.
So I want to sync save the user information in the same cache or cookie so both expires at the same time. I thought of using the httpContext but read it might create some problem. Currently I am using a session but it is not a good choice. I found some other solution but they are very old.
Thanks
As long as there is no sensitive data cookie seems to be the best choice. You can also use the MemoryCache option but it will be shared by all users.
I'm implement aspnet identity with my MVC5 project. I have configured my project to use cookie authentication, form authentication and external authentication (facebook and google). Everything work fine.
Now i have a requirement to log whenever user log in system and i need to do some further logic. For the form authentication and external authentication i have a controller action that i can add my logic. However for the case user just come back system via cookie, how do i handle it?
I'm sure there's a better way to handle this, but a basic method would be to track all activity by the user, and then use timestamps to determine when a user was last active on your site.
Discussed here: Track user activity/actions for an asp.net mvc website?
OnExecuting filters here: https://msdn.microsoft.com/en-us/library/gg416513%28VS.98%29.aspx
My team currently uses WebForms for projects, but I'm trying to convince everyone to switch to MVC. One of the problems that I'm running into is with authentication. I can't figure how to to implement our login process to work with MVC.
Our authentication is done via mostly a web service (we pass username & password and are told if it is valid or not), but occasionally we use ActiveDirectory for logins.
Right now we are using sessionstate to store information about the logged in person. How would I translate this to ASP.NET MVC? I've read a lot about various things -- Claims, Roles, MembershipProvider, IProvider, ASP.NET Identity, OWIN, but ASP.NET has been evolving so rapidly that I'm afraid that I'm reading old information on StackOverflow.
Right now we are using sessionstate to store information about the logged in person.
Don't do this. Ever. Not in WebForms, or MVC. It's highly insecure and easily spoofed. Session should never be used for anything to do with Authentication or Authorization. Plus, Sessionstate is volatile, and IIS can dump your session at any time, losing synchronization with your authentication.
The solution to your problem is very simple. You already have the authentication in your web service (though I question whether this would be secure either, given your Sessionstate authentication methods, but that's a different argument). All you need is the Authentication portion, which is easily provided by FormsAuthentication to set the cookie to allow logins.
You Validate against your service, if you succeed, you call FormsAuthentication.SetCookie(), and then you add [Authorize] to all the MVC action methods you want to protect. It's really that simple.
If you need to have information available about the user, then you would create a custom IIdentity and/or IPrincipal implementation that provides that information, making it secure (secured by encrypted cookie) and easy to access.
I have reviewed some of the similar questions on this site but could not find one with an answer appropriate for my situation.
I am using asp.net mvc, and it is communicating securely with stateless wcf services. for each service call, i need to pass in the username and a few other ints for identification purposes. - not password, the services are not authenticating.
I am using forms auth to authenticate the users. I am just not sure where, after the user logs in, I should store their username and other account details used for the scope of the user's time logged into the site. suggestions for webforms apps include in "Session". Is there an equivilent alternative in MVC? is storing the info in the forms auth cookie the best solution? it seems like it would be slow to have that info in a cookie as opposed to somewhere else in memory..
thanks
If you need access to a select few bits of information about the current user over and over again, you could combine FormsAuthentication with a custom principal implementation.
The Forms authentication mechanism will write a cookie to your client's disk, and will recreate the custom principal based on that cookie for each call. You could e.g. store something like a user "level", a user "profile" or other small chunks of information, which would then be accessible through the HttpContext.Current.User at any time during the lifetime of your request.
Check out these resources on the topic:
MSDN docs on How to Create a Custom Principal Identity
Using Custom Principal with Forms Authentication in ASP.NET
and I'm sure googling or binging for "ASP.NET custom principal" will render quite a few more hits for you!
yes, unless it's a lot of information, the preferred location is to store it in the cookie. Aside from that, session is the next best place.
I'm using ASP.NET MVC and I am trying to separate a lot of my logic. Eventually, this application will be pretty big. It's basically a SaaS app that I need to allow for different kinds of clients to access. I have a two part question; the first deals with my general design and the second deals with how to utilize in ASP.NET MVC
Primarily, there will initially be an ASP.NET MVC "client" front-end and there will be a set of web-services for third parties to interact with (perhaps mobile, etc).
I realize I could have the ASP.NET MVC app interact just through the Web Service but I think that is unnecessary overhead.
So, I am creating an API that will essentially be a DLL that the Web App and the Web Services will utilize. The API consists of the main set of business logic and Data Transfer Objects, etc. (So, this includes methods like CreateCustomer, EditProduct, etc for example)
Also, my permissions requirements are a little complicated. I can't really use a straight Roles system as I need to have some fine-grained permissions (but all permissions are positive rights). So, I don't think I can really use the ASP.NET Roles/Membership system or if I can it seems like I'd be doing more work than rolling my own. I've used Membership before and for this one I think I'd rather roll my own.
Both the Web App and Web Services will need to keep security as a concern. So, my design is kind of like this:
Each method in the API will need to verify the security of the caller
In the Web App, each "page" ("action" in MVC speak) will also check the user's permissions (So, don't present the user with the "Add Customer" button if the user does not have that right but also whenever the API receives AddCustomer(), check the security too)
I think the Web Service really needs the checking in the DLL because it may not always be used in some kind of pre-authenticated context (like using Session/Cookies in a Web App); also having the security checks in the API means I don't really HAVE TO check it in other places if I'm on a mobile (say iPhone) and don't want to do all kinds of checking on the client
However, in the Web App I think there will be some duplication of work since the Web App checks the user's security before presenting the user with options, which is ok, but I was thinking of a way to avoid this duplication by allowing the Web App to tell the API not check the security; while the Web Service would always want security to be verified
Is this a good method? If not, what's better? If so, what's a good way of implementing this. I was thinking of doing this:
In the API, I would have two functions for each action:
// Here, "Credential" objects are just something I made up
public void AddCustomer(string customerName, Credential credential
, bool checkSecurity)
{
if(checkSecurity)
{
if(Has_Rights_To_Add_Customer(credential)) // made up for clarity
{
AddCustomer(customerName);
}
else
// throw an exception or somehow present an error
}
else
AddCustomer(customerName);
}
public void AddCustomer(string customerName)
{
// actual logic to add the customer into the DB or whatever
// Would it be good for this method to verify that the caller is the Web App
// through some method?
}
So, is this a good design or should I do something differently?
My next question is that clearly it doesn't seem like I can really use [Authorize ...] for determining if a user has the permissions to do something. In fact, one action might depend on a variety of permissions and the View might hide or show certain options depending on the permission.
What's the best way to do this? Should I have some kind of PermissionSet object that the user carries around throughout the Web App in Session or whatever and the MVC Action method would check if that user can use that Action and then the View will have some ViewData or whatever where it checks the various permissions to do Hide/Show?
What you propose will not work. Actions can be cached, and when they are, the action (and hence your home-rolled security) does not run. ASP.NET membership, however, still works, since the MVC caching is aware of it.
You need to work with ASP.NET membership instead of trying to reinvent it. You can, among other things:
Implement a custom membership provider or role provider.
Subtype AuthorizeAttribute and reimplement AuthorizeCore.
Use Microsoft Geneva/Windows Identity Foundation for claims-based access.
Also, I completely disagree with ChaosPandion, who suggests making structural changes in your code before profiling. Avoiding exceptions for "performance" reasons is absurd -- especially the idea that the mere potential to throw an exception for invalid users will somehow tank the performance for valid users. The slowest part of your code is likely elsewhere. Use a profiler to find the real performance issues instead of jumping on the latest micro-"optimization" fad.
The correct reason to avoid exceptions for authorizations is that the correct way to indicate an attempt at unauthorized access in a web app is to change the HTTP status code to 401 Unauthorized, not throwing an exception (which would return 500).
Define your authorisation requirements as a domain service so they are available to both the web and web service implementations.
Use an authorisation filter to perform your authorisation checks within the web application, this should be as simple as creating an auth request object and then passing it to your auth domain service.
If the authorisation fails, return the correct error - a 401 as indicated by Craig Stuntz.
ALWAYS authorise the action. If you can hide the link to unauthorised users - thats nice.
Simplify your views / view logic by writing a HtmlHelper extension method that can show / hide things based on a call to the auth domain service.
To use your authorisation service from the web service is simply a matter of constructing the auth request object from something passed in via the service message instead of from a cookie passed by the users browser.