I'm trying to analyse FusionAuth as possible Identity manager for our current solution.
Our current solution is deployed at customer premisses or cloud, and helps them manage their processes (with their company users).
Our current solution is in early-transformation for micro-service solution, and we're trying to extract the user + authentication flow first. We thought maybe using some JWT solution for authentication could be a thing.
We have the use case that companies may have different root-level departments, and an user may belong to more than one department (or its children departments)
How currently is solved, is that at login time if such an user is making the login then it has to choose which root-level department he wants to login into.
We would expect that our new solution with JWT would contain such high-level department on the token information
Users logged-in for a root-level department can't access all data from other departments (only some base data)
I'm trying to understand if such use case could be acomplished by tenants / applications / groups, but I don't see how the same user could belong to many of them and have the possibility to choose one of them at login time
Would anyone suggest an approach to the problem, and if Fusion Auth could solve it?
Also some of our customers do use LDAP, and ask us to integrate the login through their AD (we make the login with AD, and import / synchronize the users). I've seen an open issue for AD integration, but not sure if that is going to be adopted?
One way to handle this is to present the user with a Department Select Screen prior to sending them to FusionAuth. This screen would list out the Departments and the user would select one. Once they select the Department, they would be redirected to FusionAuth's OAuth where the Department is the client_id. This also means that you need a FusionAuth Application for each Department.
Once the user has logged into FusionAuth, the JWT that FusionAuth creates will contain the Application id. This will allow you to identify the Department that they logged into.
Related
We are using Auth0 as the Identity Provider. We want to support both Individual Users and Enterprise users (Users who are part of an Organization).
By looking at the user profile, could not find any distinct field which can help me identify the type of user. Although Auth0 has extensive documentation, isn't helpful either for this area.
How can we identify the type of user from the User Profile of the User. I have tried GET /<user_id>/organizations but it won't help if the user logs in before the Organization is registered in the Auth0.
Thanks in advance
I am in the process of designing a Blazor Server app that sits on top of a single MSSQL db.
I have done a fair amount of research and learning on the subject but I am still very new to Core Identity, so I need to better understand how it is meant to be used so that I can properly design the Authentication and Authorization pieces.
The app will consist of organizations. Users can belong to one or more organizations and within each organization, can belong to one of two roles: Coach or Student. But the Coach in one organization could be a student in another organization, and a student could be a student of more than one organization. But all of this should be tied to a single user account/login. If a user belongs to more than one organization, they will be presented with a screen to select which organization they want to access after completing the login process. Once they have selected the organization, their activity and access will be limited to that organization.
What would be the proper way to handle this type of arrangement? Since one user could be a coach in one org and a student in another, are roles the proper way to handle that? Or would those be claims where for example I would store the ID of the organization as the value of a claim called "Coach" or "Student"? Or some other way?
Initially, I was planning to only use Identity for Authentication and then use my own custom logic to perform Authorization based on these criteria, but I don't want to reinvent the wheel if I don't have to.
Thanks in advance for your guidance and recommendations on this.
I'm trying to work out how to structure a database schema that allows me to have multiple authentication sources for the same end-user.
For example, my web app would require users to sign in to utilize many of the functionality of features of the app. However, I do not want to be responsible for storing and authenticating user passwords.
I would like to outsource this responsibility to Google, Facebook, Twitter and similar identity providers.
So I would still need a database table of users, but no column for a password. However, these are authenticated would not be my concern. But I would still need to somehow associate my user with the identity providers user id. For example, if my user signs up with Google, I would store the users Google ID and associate this with my user. Meaning next time the user makes an attempt to login and is successfully authenticated at Google, I would make an attempt to find any user in my system that has this associated user id.
I've been trying to look for some common and recommended database structures, with no luck. Maybe I'm searching for the wrong terms for this because I cannot imagine that this is an uncommon way to do it. StackOverflow seems to do something similar.
The way I imagine it, it would allow me to associated multiple authentication sources for one app user. Meaning once I've signed up with Google, I can go to my settings and associate another account, for example, a Facebook account.
How should I go about achieving this in a flexible and clean way?
Thanks.
You need to know what data you have to save in your db to authenticate a user with a third party login.
For example, once I used Google to login users in my app, I save Google user id first time a user logs in and get data the next time.
You could have an entity with third party providers, so you will create a table with 2 values, user_id (your user data) and provider_id (Google, facebook, twitter...).
If you are going to use just one provider then you could add provider_id field to your users table.
Planning on creating a Google Assistant Application that allows our customers to access business data. The problem I am having is understanding how a given user would link his account to his "instance" of our multi-tenant solution. I think the deeper problem is know which Tenant URL to associate with a particular account. I know I can implement the Accounting linking using Oauth, I have just yet to see how this could work with a single Assistant App accessing multiple tenants depending upon account.
You can get additional info from the user, by asking him, and save that in your context, and then you can request for a sign in. this way, during the sign in process, you can use the context to sign in the user into the proper tenant
I'm unsure if this is a programming question or a database question
I'm making a web api, I use bearer token authentication and its working really well, I can login get resources and logout, I can added users and users can add users which ill explain next.
I have 3 main roles, CompanyAdmin (users who created the account in the first place), CompanyUser (the user company admins make) and StandardUser (users the company users make)
Everyone has a row in the users table for logging in, now when a user logs in I don't want them loading up fiddler and seeing another users data by manipulating the url, I want to make sure companys cant see other companies data, users cant see other users data from the same or another company.
I'm using WebAPI MVC, SQL azure database and the website is hosted by my hosting provider. all accounts that can log into the site and access the api have a row in the users table from which only a few tables hang off it mostly for claims, roles, profile, company data etc.
Any help, pointers in the right direction would be helpful thanks
Getting the access to the data by simply passing the request payload means, that there is no security in the broker between the client and database. There are some ways to secure the access that are exist and actively used, one of them, for example, is the simple, basic authentication where you are setting the context by passing credentials, (dis)advantages are described on the same page above. Or using token-based authentication (more detailed walkthrough).
So, please avoid the possibility to do a just pass-through the request through the Web API.
Also you may check that old but good book on creating the multitenant solution and partition your database for customers/tenants on Azure. Some titles from that are not available already (Ex.: Federations), but examples of how to partition your SQL Database and some code samples should work.