I'm writing a ruby on rails application using mongoid and I'm wondering about the security implications of storing users and admin users in the same document. My current implementation is using devise and kind of modeled on how activeadmin does it. The admin users are in a separate document so there isn't any chance of someone escalating their privileges. This is a public facing site and there is some financial information involved.
But i'm curious if maybe I'm just making more work for myself and this is kind of unneeded.
There shouldn't be any implications as long as you prevent users from being able to update the mechanism for privileges. If you have a boolean flag called is_admin for example, ensuring that you have attr_protected :is_admin is vital to protect against mass-updated from changing this privilege.
Related
I am fairly new to coding in the .Net environment. I am having trouble finding "real-world" examples on authentication/authorization using Identity. Most examples I come across are primarily textbook examples that use the ASP .Net registration template.
I am trying to find guidance on where to look (yes, I Googled and I get very unrealistic/unusable use cases or "classroom" examples) or how to do this.
I work for a small school and I am trying to build an application (possibly Blazor - just experimenting with various technologies now) that allows both students and employees to login into a portal and view their relevant data. I have an Employee table and a Student table based on POCO classes. When I add identity to the project it creates Users and Roles tables as well.
I would like to have the "Users" table based on the Student and Employee tables - not have a separate users table. I do not want to have a "registration" option either. I would like the option for an Admin (which would fall under an "Employee") to be able to add users, but not use a registration page.
How would I implement Identity and Roles without using all the extras added? I am using .Net 5.0.
Thank you for your time and pelase forgive the English - it's new to me as well.
I understand what you're trying to do. It IS possible to Create a Custom AuthenticationStateProvider
But unless you have a VERY robust database already, I wouldn't do it. Getting the default system set up and migrating users will take at most an hour. Setting up your own custom authorization system is likely to take you MUCH MUCH longer.
Having different users in different tables is not a good design plan. They all have names, phone numbers, e-mails and so on-- put them on one table.
Hi Derrick and welcome to the community! #Bennyboy1973 is correct, in that both your Students and Employees are all "Users", so they should all be stored in the same table. To add to that response a bit, probably the simplest way for you to manage them is by using Roles, so the Students could be in one role and the Employees could be in another. By having a role attached to each, you can then use the roles as a filter in your queries and you could also restrict the access and actions each type will have based on the role they are in.
Regarding having administrators add the users to the database without public access, this can be done as well. Once you get the default identity system up and running, you can scaffold out the whole system so it can be modified, and probably the easiest way to achieve what you are after is to then modify the default registration (signup) page so that it requires the user to be authenticated to reach it, and then implement a confirmation email to activate each new account.
There are a few things with this approach that you need to be aware of as well.
Since the admin will be setting up all the other user accounts, you should modify the email confirmation chain to require a password reset at some point. The administrators can have access to the user's information as needed but shouldn't have the user's passwords.
Identity Server will store passwords in an encrypted format, and you'll need an initial user in your database. What this means is that you will have to "seed" an initial admin user into the database that you can use to sign in and get started with everything else. You'll have to research how to do this, as it isn't as simple as just accessing the database directly and adding the user and roles because of the encryption. The program you build should be designed to do this for you on either the first run or if you are connecting to a new database, using a username and password that you know. It will then store the user properly that you can use to sign in as Admin, then change the admin password. This makes the whole thing more secure.
This all sounds like a headache, but it's worth it to work through and know how it all fits together. The, as mentioned in other answers, you can migrate existing data into the database.
Currently I'm building a web app. So far I only have regular users. However, due to some requirements I need to have special admin accounts for the app administrators. I'm wondering now how these are usually implemented. The requirement is, that they use the same login mask as regular users and behave the same except for the additional capabilities. To differentiate I could put an admin flag into the users' profile or put the admins into a separate table in my DB. Maybe the the second option scales better for potential additional user groups. Also, how could these admins be signed up? I don't want to use predefined usernames I check against in the login handler. I know the question is rather general. I'm just looking for some directions.
Since you didn't give information about the platform(s) you are using, I can only give theoretical answer. While a simple "isadmin checkbox" will do the job for only separating normal users and admins, but if you will need another user type such as "power users" etc. you will keep adding new columns to your table, which is not ideal. Basically you can use a "Role Based" or a "Permission" based approach. In Role based, as the name implies, you assign each user a role and give access to specific resources depending on the role. In the "Permissions" approach you define for each user the permissions they have (resources to access, actions they can perform). Also you could combine these two approaches, where you assign each user his role and define permissions for each role.
I'm using devise on Rails 4.0. I need non-login users, that is, people who are considered part of a team but never need to log in or interact with the app, they just get emails, appear in different lists and so on (in the future, however, they can potentially become users).
Ways I'm guessing how to do it are to:
programmatically add them, then -
possibly generate the devise views so I can alter them for non-login users?
write the controller to block non-login users?
I need to know what would be the basic steps for implementing non-login users.
I am working on a ruby on rails application with many types of users. All users will share the basic properties of email address and password, along with the timestamp fields for created_at and updated_at. Other fields will be unique to the type of user (think Employee, Vendor, Manager, etc.) I have been looking into Single-Table Inheritance but that does not seem like the right pattern for this. The other option seems to be to have a User model that has_one of the other models. It is also possible for a User to have multiple types, ie. Employee and Manager could be the same User. I also want to direct the user to a specific page on login, based on what type of user they are. Would this be best done through constraints in the router or a large switch statement on login?
You probably need to define user roles. I suggest CanCan to manage your roles and access privileges.
One way to to implement different fields on a single table would be to use NoSQL (hstore) from Postgres. This is a simple introductory tutorial.
Here is and example of using it with Rails 3.2+
I've got a rails 3 app in beta right now that uses Devise for authentication for users, and need some advice. I want to add an admin-user that has some additional abilities, but I will be the only admin user (or admin users can be created via terminal - ie people cannot sign up to be admin users). All regular users have the same abilities. I was just about to use cancan to separate abilities based on user roles. Then it occurred to me that using cancan may just be overkill. does it make sense to just create a different class of user instead? Am I giving anything up by doing this?
I can foresee in the future that if this app is successful, there may be different roles for users (a free versus paid account, etc). Even in that case, does it make sense to NOT have an admin user via devise? Thoughts?
Thanks!!
If you only have two types (users and admins) it seems perfectly fine to have two classes. It might even be easier to implement than a full-fledged role system. But if it is foreseeable that you will get more roles in the future it would be better to lay a solid foundation and use a role system from the start.
If you are the only admin, I would create a field in your user model called Admin and then when you are going to add a function that is only for you, use the admin? check in your code.
For most of my projects, I have been using Devise and then use Option 2 from their Admin Role Wiki which is super easy to implement.