My app can handle Medics and Patients.
So far everyone can login and perform different tasks on the site.
We want to avoid forcing people that are Medics AND ALSO Patients to create a new User Login and password.
So a Medic which is also a Patient should keep his same login and password but we are thinking that as soon as the person with this dual privilege logs in they should PICK which role (and maybe store in a session variable) he wants to log in as.
Is this recommended or can you please provide me with an alternative?
Please help. thanks in advance
Your suggestion for roleselection after authentication IS a preferred way of working with your users. Your application can perform authorizations based on the role, rather than on the user. It is also important for the user to unmistakenly be aware of the role activated performing certain tasks.
One small suggestion I could give is to be able to switch this role dynamically, at any point in time in your application, without having to re-authenticate or get back to some kind of main page in your app. That fast role switch would really improve its usability. And always have the activated role display somewhere in the screen.
Do Medics have more privileges?
Somewhat like an "Editor" is also a "Registered User".
You wouldn't need an extra logon, you would just need to setup the hierarchy and what tasks/abilities a Medic has over a patient - if that's your scheme.
You should create another role. MedicAdmin for example.
Related
I have a Flutter app where most of the users should never log in. I also use this same app for a small selection of users that I personally manage and would like to allow them to create a Firebase account, preferably just with by giving them a password to access the account creation page. Ideally I don't want just anyone to be able to create an account, only those who I have personally given access to. Is there a way I could password protect the account creation page so that only those with access to the password could create an account? Perhaps there is another way to do this? Ideally, I'm not looking to get into a situation where anyone can create an account and then downstream I have to authorize that account so that it has the correct access. I really just want only those with the access upstream to be able to create the account. Perhaps this is not logical but this seems to make more sense than letting accounts be created by anyone and then approved by me after the fact. So my question really is, how do I password protect a page in flutter? Or is this just a bad idea and should I work to manage things downstream? Or is there another solution I have yet to consider?
Have you considered using something like a dynamic link that navigates to the specified page in the app when clicked. firebase_dynamic_links might be of help. Only those who have the link will be able to access it and I presume that you could manage the link actions from the Firebase console.
You could also opt for simplicity and create a password field that pops up before your account creation page
In a generic asp.net website with Membership, Roles and hashed passwords enabled, I would like to provide the administrators with impersonation so that they may browse the website as that user would. The website should function as if that user is logged on and then be able to revert to their own login.
What is the best approach to achieve this?
An example use-case: A website with two types of users: 'Buyer' and 'Admin'.
The website provides a 'Purchase' button to buy something specifically provided to the user by the admins. i.e only that buyer can use the purchase button and make a payment.
User has trouble so a support admin can 'impersonate' the user's login and purchase on their behalf or 'see' the trouble they are facing.
Without impersonation, the only way is to allow this in code and that negates the purpose of 'seeing the user's issue'. Not even if I was not using hashed passwords and had used FormsAuthentication.SignOut() and manually logged in the admin as the user.
I hope i am making sense above.
Take a look at this sample on codeproject.com. I think it does what you're looking for.
I don't have the code we used to do this in front of me (assignment from a few years ago), but there are bits in the Membership API to sign someone in using code. I will not have access to the code until this weekend, unfortunately, or I could quickly share the bits and be done with this.
I do remember you had to get the user first, as a MembershipUser, using the Membership class. I am not sure, from this point, whether you had to validate against provider or what.We did use a custom provider, but I forget whether it was related to this solution.
Regardless, examine the security bits, focusing on membership and membershipUser.
I know this is a question that has been asked over and over but I'm attempting to implement permission based rather than role based authorization in an ASP.NET MVC application. So instead of just having high level roles like Manager, Admin, or User, I need to have permissions like ViewTask, AddTask, DeleteTask. I have read a ton of comments on this and it seems like the easiest solution is to just treat roles as permissions and define "roles" of ViewTask, AddTask, and DeleteTask.
Is such an approach really a good idea? Some of my concerns are that you could end up with over 100 roles depending on the size of the application which would then rule out the ability to do role caching in cookies and thus every call to User.IsInRole hits the database. If every action method is going to be decorated with [Authorize(Roles="XXXX")] am I going to see serious performance issues?
My other issue is that I still want to keep the concept of a role around so that an administrator can simply associate a user with a role that has a predefined set of permissions. Using the approach above my thought was to create a separate entity in my application named Group and that Group would be responsible for keeping track of the ASP.NET roles that are assigned to that Group. So, when a user is associated with a Group, I can retrieve the ASP.NET roles that need to be assigned to the user and add all the roles.
Has anyone implemented a system in such a way? Any opinions or thoughts on this approach would be appreciated.
Thanks
I agree with #jlew about caching the user's data and when the cache expires - just reload it. There's no use trying to force this data to stay persistent. Additionally, if you want to move away from the ASP.net role providers, you could roll your own security as I've described in this reply. This has the advantage of allowing very custom security solutions for roles/individual permissions.
The following is just an idea that I've been toying around with lately (just some food for thought). Why not use the RESTful urls of MVC to define "permissions". For example:
/tasks/add could define the permission for adding tasks. These could somehow be hierarchical so that giving a user permissions on /tasks/add also gives them permissions on /tasks. Then, you could use a global action filter that would build the URL given the route values. This would also allow really interesting approach for individual item security configurable via runtime. For example, /tasks/edit/23 could somehow grant edit permissions on task with id 23. Anyway, this might not even be helpful at at all... but it's just thought I thought you'd like to maybe consider.
Cheers!
We solve the problem by caching the principal on the server side, so that the "permission roles" do not need to be in the cookie and we do not have to re-load on every request. You can actually get around the cookie size limitation by chunking your cookie data into multiple cookies (Windows Identity Framework does this.) But, you may have bandwidth or other concerns with big cookies.
I'm trying to figure out how when using the default asp.net forms authentication stuff one can change the roles that a user has dynamically. In our case a user has access to many accounts and there roles can change per account. This doesn't seem like rocket science to me but I can't figure out I would do this. Does anyone have a experience trying to do this or a link that would be helpful?
UPDATE:
Just to clarify. We know at startup that User X has access to account #1 with roles 1,2,3 and account #2 with roles 1,2.
So first off I have to handle this part of the problem. Getting their roles based off their current account. For this I think I'd use a RoleProvider. The problem I'm trying to solve though is once ASP.Net has a User how do I tell it to invalidate that user or refresh that user so it would hit my custom RoleProvider (or what not) again.
Roles.AddUserToRole() should take care of adding the user to a role.
For removing: Roles.RemoveUserFromRole()
http://msdn.microsoft.com/en-us/library/system.web.security.roles.aspx
I'm rewriting a website and going from a home-grown authentication model where users logged in with their account id (numbers) and password, to .NET FormsAuthentication where users will login with a username that they choose (or is available) and a stronger password. There are over 38K existing accounts and I'm trying to decide if the existing users should re-register or if I should write some code to do this on their behalf. I've already ruled out creating the usernames for the users because they won't be able to change their username. Luckily we don't have any users named Brenda Utthead.
If the user re-registers, some may gripe about having to do this step again and it may raise some support calls, but I stay with the standard process that everyone has to do. Or I can allow the user to login with their existing userid and password and then optionally give them a grace period to convert their account. I'm hesitant about the latter because it's special code and a possible threat vector because it bypasses the standard authentication mechanism and allows users to log in using less secure credentials.
This application currently accounts for about 40% of our website traffic and I'm not worried about users not coming back to the website because of the possibility of them having to re-register.
What does everyone think?
If you want your users to come back your best bet is to convert their accounts and send an email explaining the transition.
Do not make them re-register whatever you do.
You'll lose half of your users if you do that.
Give them a service so that they can enter their previous user id and have them provide their email address. Email them at the address provided and have them login with their email address as their new user name.
I am about to do the same thing. I am writing a migration page where the user logs in with his/her existing credentials and behind the scenes, I write out to the asp.net membership tables. Do a check first to make sure they haven't already migrated for all subsequent visits.
Don't make them re-register. A little work on your side is all it takes and you need to keep your customers happy.
After listening to everyone's suggestion, I've decided to modify the login. I look at the username they provide and try to guess that they're an existing user. Then I look them up in the old table and if I find a match take them to a conversion screen. There they can quickly convert their account or skip the whole process and login temporarily. The conversion form has fewer fields to fill out b/c I was able to authenticate them against the old user table so I don't need them to provide as much info.
I'm not thrilled with skipping the conversion but that option is only offered for the first 45 days from go-live.
Either convert them or find a way for both membership models to exist together, and somehow convert each user across at login or something.
Think about how long it took to get the 38k members and ask yourself if those were all wiped out, would those same people go through the hassle of signing up again. If you've got a really strong community you should be ok, the hit would just be a matter of time till you're built up.
The other thing you could do to mitigate the risk would be to send out a email, although spam blockers may filter them you could get to a high percentage of your users and tell them about the new membership stuff. Might get some older people back to the site as well in the process.
The biggest challenge is converting all the data that is associated with the user's accounts. People are going to be really upset if they've built up some sort of reputation that you're going to destroy with a new membership system.
This website is a check your balance type of website. It's not a banking site per se, but it exists as a convenience tool to users. I don't believe it would be realistic for users to cancel their accounts because they are forced to re-register.
I do like some of the ideas I'm reading in the responses though.
I would migrate their information and then on their first login ask them to confirm that their membership info is correct (just to be anal).