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.
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'm building a couple of ASP.NET MVC websites that will share a database (because they share data under the hood). That said, logins between sites will not be shared at the moment. For reference, I'm using NHibernate for data access with SQL Server under the hood (currently).
As currently laid out, the system has tables for Sites, Roles, Users, and Rights. Sites have sets of users, rights, and roles. Users can be in many roles. Roles have a set of rights. Users will be able to sign in with a username and password, but I don't want to paint myself into a corner - I might want them to be able to use a google or facebook login later.
Now, I'm a little confused as to which path to take with regard to securing the site. I'm not enamored of the old school membership and role providers for several reasons. Chief among these is that I won't be restricting very many things by roles; things will be restricted based on user access rights. I'm looking at the following few scenarios for authentication.
1) I want to be able to specify rights required to use a controller method via an attribute.
2) I want to be able to quickly query and see if a user is in a particular role or has a particular right.
So, I actually have a set of questions, but they are kind of intertangled. First, what should I do? Just a custom authorization attribute? Second, what's the workflow on login and the like? What are the steps required for this to work properly and securely?
I realize these are sort of noobish questions, but in the past I've gotten by with the old provider way of doing things. I don't particularly care for that and would really like some better suggestions. So I guess everything old is new again for me.
I would flee the Membership provider from MS like the pest. It was already badly implemented when it came out with .NET 2.0, and the recent refresh is no better.
Roles, Users, ..that's not bound to the Membership provider, you can use those on your own. Set up Authentification, create a httmodule that handles said Authentification (a simple userId for the Context.User.Identity suffices)
All you need is a User that derives from IIdentity and in your httmodule
string[] roles = new[] {"Admin", "CoolDude"};
HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(user, roles);
..and now in your mvc controller simply add the necessary authentication attributes, game played !
Make custom roles, custom mvc attributes, or query if a user is in a specific role directly
if (HttpContext.Current.User.IsInRole("Admin")) { ...
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.