I am facing a problem trying to develop an application in Yii (v=1.1). Client wants the application to has multiple databases (one per his customer). That means that we will have unknown number of databases. Also He wants to have only one user authentication system - regard of it, users would have the choise (and the privilleges) to belong in many databases. So I am considering about the way which it could be developed.
Do you have faced something like this?
Well you should first better define your goal because it is not that clear to me what you want to accomplish, but how I see it.
Decide where you want to store the users:
Should the same user be able to connect using the same login info to two different customer databases?
Do you need to manage all users of all customers from one single place?
You could have the following situations:
Store users only in one common database, not in customer databases:
when logging in tell Yii to use the "common" database for the User model
you could have also a common application that handles user management
you could also provide the customer with the possibility to manage his own users
you could either have a "customer" field in the Users table to indicate to what customer it belongs, or you could have a "users_customers" table and after the login screen prompt the user with a "choose customer" screen, so one unique User can login to multiple Customers
Store users only in the customer databases:
if you don't need for a common place to manage users, or don't need to share them between customers, simply have a User table in every Customer database, this way user "alex" could exist in both databases with different login information
here you could simply add another field in the Login form (yes I've saw one application that does it) for example instead of Username and Password fields, ask for "Office, Username and Password", and the Office would be the name of the Customer database. Or you could even use only Username field and force users to enter something such as "alex#office" as Username, then you split that by "#" and you know to what office it belongs.
then simply use that information both on Login screen and on session to tell Yii what customer database to connect to
So as you see it could be done in different ways. Once you choose your way, you would need a implementation.
If you don't know how to do the implementation maybe I could provide more technical information related to Yii.
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.
I have one table lets say TBL1 for registering the users and it contains close to 10 columns in it.I am adding all the new users to this table.Now for doing login for those users, should I point my DAO to this TBL1 for validating the users or I need to have separate table which will deal with login part.
Just a general doubt,whats the best way to maintain information about new user registration and validating users using register information.How do you register and allow users to login to your app ? are both insert and read happens from single table or from different tables ?
Here's the logic I would use:
I would register the NEW user in the registration table like you described above
When they fill out their username n password to login, I would first check for existence of that user in the registration table or TBL1. If they exist, then use their username and hashed password they used when they first registered from TBL1 or registration table to validate against their username and password on the client side i.e in browser window.
If those two don't match, i.e if the infos from the registration table doesn't match that provided in the login form on the client side, then you know they entered a wrong username or password.
To answer your question, you do NOT need a separate table for login users if you already have a registration table. You could use that registration table to do the validation when they go to log in. You can do both an INSERT and a READ to that same registration table, NO NEED for two tables there. Hope that helps you!
It depends on your requirement of application and security concerns. Of course creating a separate table for log in information is good practice.
If you have separate table for USERNAME and PASSWORD you can set limited rights on it. So only a specific part of your application can access it. And you can allow other registration details to be accessed more frequently if you need.
You might have some service that authenticate the user. So you can give access to only authentication and resetting password services for your log in table.
Even if you need to add or change something in your registration details it does not affect your authentication process at all.
It depends on Requirement and many factors of application:
Case 1: Requirement is small database having 10 tables, then you can maintain the login and registration information in the single table - TBL1.
Case 2: Requirement is big having say more than 10-20 tables, then it is good to use Normalized Level and so Create 2 different tables for registration and login and mapped with primary key.
I'm trying to design MVC4.5 website on Azure with latest EF but stuck in setting up membership and role base authentication.
I'm somewhat lost in MembershipProvider, SimpleMembershipProvider and ExtendedMembershipProvider.
I found that unlike SqlMembershipProvider the SimplememberShipProvider is not designed to store multiple applications (through ApplicationName and ApplicationID) in a single database and map users accordingly so that business can run multiple applications with only one database.
I hear all praises of SimpleMembershipProvider, my question is how should the database/providers be designed so that I'm able to store user's in association with respective applications in a single database. User registration info must be completely independent from same user name in other application. I also need new features of Open Authentication.
Broadly, my queries are:
Is it possible to use SimpleMmebershipProvider to differentiate between multiple applications in a single database.
I'm thinking to modify existing schema structure made by SimpleMembershipProvider to include ApplicationId column , but then how would even a custom provider that is inherited from Extended membership provider add ApplicationId against any user.
Is there any other provider available or any article that would guide in implementing custom membership provider with custom database design along with features of open authentication.
Or am I going with completely wrong approach?
Answering to the queries of BernardG
Do you want a "head" url/site, then redirect users to the proper
application, or
No, sites should not appear related nor will be redirect to other.
Do you want a user to enter into any application and
then be redirected to another one he is registered in.
Again no, each application should have it's own registration process. Further two applications can have same username but these accounts would not be related.
Can a user register into any application?
Yes.
If not, how do you limit that?
Not limiting.
What do you mean by this?"User registration info must be completely
independent from same user name in other application."
Refering to answer to point 2, if there are 4 applications with one database and a user registers for one application, he must need to register again to have access to other application. Hence for any user the sites must not appear related.
Do you want to duplicate users info into each applications?
As per my understanding of the question a combination of username and email address (considering this combination makes any user account unique) can again be stored against another application even with different profile information.
Actually I'm used to the classic membership approach used in ASP.net 2.0 and I'm missing the application Id column for separation.
If I may, I believe your question has a lot more to do with design and establishing clearly the features you want, rather than a specific membership provider, knowing that you can do about anything you want with SimpleMembership.
My questions, and I believe those are the questions you have to ask yourself before going further, are:
Do you want a "head" url/site, then redirect users to the proper
application, or
Do you want a user to enter into any application and
then be redirected to another one he is registered in.
Can a user register into any application?
If not, how do you limit that?
What do you mean by this?"User registration info must be completely
independent from same user name in other application."
Do you want to duplicate users info into each applications?
It looks to me that this is all about database(s) design, and analysis, for your real needs. Once that's properly done, the part about membership tables will be easily solved.
The application is written in Ruby on Rails but the problem I am facing is more a design matter than language related.
the system provides service to a number of users to maintain a registry. So it relates persons to things. As such it has a model called Person representing owners and it has a model called User representing those who manage the registry.
Now a new requirement has arisen to allow People to log in and be able to change personal details which it was not required for the original design.
The question is how to refactor the application to allow this new requirement in?
One easy solution is to create Users for each person who request login credentials and link user to person entity but that is not very DRY as some fields such as firstname, surname etc. are in both classes and in particular, that is precisely the data people will be able to change. Besides User and Person are stored in separate tables.
The other possibility I was considering is to make one to extend the other but having data in separated tables it makes it a bit messy. Additionally the logical extension would be User <- Person as an user is (generally) a person but thinking on the implementation Person <- User is quite a lot easier.
One last option could be to scrap User and move login credentials into Person leaving logon fields empty for those who won't log in and half of the fields empty for those just login in.
Can you think of a better solution?
You could think about how this should ideally work if you were to write the application bottom-up, and then figure out how to make a reasonable compromise between that and your current setup. Here are some generic inputs.
As authentication is involved, you need an "Identity" that can be authenticated. This can be e.g. an email address and an associated password, with email verification.
An Identity can potentially be associated to multiple "Roles" and someone authenticated with the identity can choose which role to perform, e.g. "I am now an administrator" vs. "I am now a regular site user", and the role defines the user's current rights for the logged in identity. Or if you don't need that level of complexity, you can say that an Identity is a (single) Role.
You need some tracking between possible "Rights" and the Role the user is performing. E.g. the simplest setup could be the Identity or Role has some boolean can_edit_profile or can_modify_registry properties.
Whenever a user attempts to perform an action which requires certain Rights, it is simply a matter of looking up the corresponding rights set for the Role being performed by the user, to check whether the user is allowed to proceed.
For your application this may just involve adding a 'can_change_registry' property for your user objects, and check whether that property is True for any code accessing that part of the site.
I have started building a web app that has different user types - including Admins and Customers, and I want each account type to have its own users db table (sessions system etc), but with the same log in page.
The Admins don't sign up - they are issued an account, whereas the Customer sign up on a page dedicated to creating their account, so at this time and in the future, every user account type will have its own sign up page.
Yet all user account types ie Admins and Customers, should be able to sign in from the same page - without any differences - in the log in form ie no drop down to select user account type being logged into.
My goals are to have:
all user account types (3+) log into web app via same form,
no need for any visible user account type identifier eg in the formatting of username,
as secure as possible 'invisible' user account type identifier.
One solution I've thought of is: hashing the passwords differently per user account type, but with some constant in the hash that can be read on sign in to identify the user account type, that then points the log in process to the right db for that user, but that would require some kind of constant in the hashed output... and I'm stuck. Am I on the right track?
Does anyone know of a script/how-to/or article that covers such a process somewhere?
This must be used in a lot of current web apps.
Thanks
Where we've had to implement multiple account types (in big systems I should stress) we always settle on a general (Users) table to supplement the additional tables (Administrators, WebUsers, Suppliers etc)
The Users table would link to either an Administrator, WebUser etc and any 'generic' functionality (i.e. login, logs, recordlocks) would link back to the generic Users table.
Then from a Users record you can deduce what type of account it is and decide what they can/cannot do.
I should stress though that this is only because the structure of these tables is so different that they cannot all be stored in the same table. If there's only 1 column different, for instance, you don't need to do all this.