Is it possible to have Symfony use doctrine entity manager for db authentication, if I have scenario where a single user has multiple rows in database, but with different passwords?
This is needed because we have a single support user used for the username, but passwords are unique to every developer.
Related
The important attributes for the User Table are:
unique id (uuid): to identify the user (and to be referenced later with other datasets for identity)
social media id: FB, Google, Apple
email id
mobile no
User can login using either social media or mobile no or email. For this 3 cases, the searching needs to be done in the DynamoDB table for its existence.
So, what would be the ideal designing of this User table (with respect to keys) to ensure the performance as well as the purpose?
For better understanding of the Use Case:
Use Case:
User can register with Social Media (any of the FB or Google or Apple) along with mandatory detail like mobile and email
User can login using Social Media (any of the FB or Google or Apple) or Mobile No or Email ID (using OTP)
The Data volume will be on the higher side.
So, all this attributes to be stored alongside with the right design of the Primary Key to fetch information correctly during login.
I don't know if I fully understand your use case, but I'd probably build it like this:
PK
GSI1PK
UUID#<uuid1>
GOOGLE#<google-id1>
UUID#<uuid2>
MOBILE#<number1>
UUID#<uuid3>
FACEBOOK#<facebook-id1>
The table has PK as it's partition key and GSI1PK as the partition key of a Global Secondary Index (GSI1).
If you want to check if there is a Google-User with a specific ID, you run a Query against GSI1 with GSI1PK=GOOGLE#<your-id>. You can use the prefix for different identity sources.
Any queries against your own UUID can be executed against the Base Table.
You can also essentially flip the attributes, but this way it's easier to transition a user from one identity provider to another.
I am trying to create a centralized authentication server for multiple Django apps (APIs). I've seen posts/recommendations but none fit exactly what I am looking for.
Overview:
Users can be associated to one or multiple projects
Users have same credentials to all projects they are associated to
Use JSON Web Tokens - use payload to add user data, sub-domain (project) to route to, role, etc
Sub-domain will not be used for login. All users will login to same site and will be routed to project they are associated to (or given list if there are multiple). SSO is optional.
Questions/uncertainties:
Q: Should the authentication tokens be created on the authentication server or on each project? ie) Each user having one auth token for all projects or have one auth token for each project?
Q: Roles will be stored in each app. I would like to send the roles along with the authentication token in the JWT. Should this data be redundantly stored on the authentication server? Another other way would be for the authentication server to access the project databases. What is the best way to handle this? Users will have different roles for each project.
Q: Auth server will have basic user information (email/username, password, first/last name, etc). Since foreign keys can't be used between databases I can use a user proxy based on usernames to create the user on each project. Do the app servers need to have access to which authentication tokens are valid?
Taking advantage of pre-existing software:
Another approach I had in mind was to use django-tenant-schemas which takes advantage of Postgres schemas where each one of my projects would be a schema (currently using MYSQL databases). Does it make sense to take advantage of this?
Can I take advantage of an IdP service to offload some of the authentication? Does this easily tie into the Django auth layer?
Your question seems to be multiple so I would split the answer too:
ABOUT THE USERS
Since your users are not part of your "mutitencancy model" you have two options here:
Replicate your user data among the different tenant databases (via triggers and what not).
Write your own authentication middleware that verifies users in the right database (lets call it root database since now on). You can use user ids to from the root database and verify manually that they match, which is a bad idea.
That means your database schema will be something like this:
root database (all common data here)
project 1 database (with it's own user data or referencing root)
project 2 database (with it's own user data or referencing root)
Now for authentication tokens
You have the same options as above:
Keep them in the root database and write your own middleware.
Replicate them.
How to implement the whole thing
Since your use case is pretty particular, you may encounter some resistance from existing software. But creating your own multitenant solution is not that hard
I have a new public-facing Django/PostgreSQL-based web site that requires users to create a new username/password and then fill out a profile that requires three more screens (forms) after the initial username/password page to complete their membership. As you would expect, I have a small number of users that don't complete the entire signup process leaving me with abandoned user IDs. Do either Django and/or PostgreSQL provide any convenient means of recovering and reusing these abandoned user IDs?
I am integrating Django authentication and login system with Facebook Login API. The problem is that once Facebook username will be the same as existing in my project's database so the only solution to the problem is to catch Facebook username and add numbers or something to the string to make it unique ? Is it correct ? How is it normally handled ?
You have several options, I'm sure I won't think of them all.
If you have an unique constraint on the field for 'username', you can add numbers to remain unique.
Remove the unique constraint on the 'username' field. Add a boolean to the user table, to identify users logging in with facebook. You are probably able to determine when a user logins with a facebook account. After logging in you can crossmatch the information with the user you have in the database. Facebook probably has some kind of 'unique' data about a specific user which you can place in your database to differentiate between unique users with the same name.
We would like to move the users from a one Identity system to WSO2 IS. Both userstores reside on a SQL DB. We would use SELECT INTO (INSERT INTO SELECT) at the database level to move the users from the old Identity Store to WSO2 IS. Will this cause any issues with the data integrity? Or should we just use the WSO2 IS APIs instead?
You have your users in separate user DB (say foo user store) and you need to move all users in to WSO2IS user store schema..? It mostly depends on the how user's password has been stored in the foo user store.
If password is stored as plain text (or encrypted as it can be decrypted), you can WSO2IS APIs to add users which is mostly the best option. You can write some tool to read from foo DB and call the API of WSO2IS. User Mgt API can be used for it. More details from here
If password is stored as hashed, then we can not use the APIs and we need to use some database level migration. You can move to username and user's password in to UM_USER table and user's attributes in UM_ATTRIBUTE tables.
But, please note, if your foo DB has used some different password hashing schema which is not supported by WSO2IS, above migration also would not be success out of the box. By default WSO2IS supports for SHA-1, SHA-2 hashing methods only. If it is not, you may need to do some customization.
However, why you are trying migrate it to WSO2IS schema? Can't you write a custom user store manager implementation for your foo DB and connect WSO2IS in to your existing user store ? I guess, it is more convenient than migrating.