I am working through Matt's excellent article on implementing the OAuth Authorization Code Grant in a React app.
https://fusionauth.io/blog/2020/03/10/securely-implement-oauth-in-react
We have a multi-tenant implementation and would like to know what the recommended approach is for determining which tenant a user is authenticating as. For example, if we have two different users in different tenants, both registered for the same application and both have the same username, is it possible to ask the user which tenant they belong to?
I think I can pass along the tenantId in the authorize query string, but this would require me to have already asked the "where are you from" question. Do I need to implement this, or can FusionAuth provide this out of the box?
I have read the documentation around login themes, but this seems to be more about displaying the tenant, rather than requesting it?
https://fusionauth.io/docs/v1/tech/themes/
Great product.. thanks in advance.
So you say this:
if we have two different users in different tenants, both registered for the same application
FusionAuth applications are tied to a tenant, so it isn't possible to have a FusionAuth application shared between tenants. From https://fusionauth.io/docs/v1/tech/apis/authentication#making-an-api-request-using-a-tenant-id
Some resources in FusionAuth are scoped to Tenants such as Users, Groups and Applications. When more than one tenant exists these APIs will require a tenant Id to ensure the request is not ambiguous.
Now, of course it is possible to have your application be shared among customers, where each customer is a FusionAuth tenant. So the question you ask is a good one. I'd rephrase it as "how can an web application or other client of FusionAuth know which tenant it is associated with?" If that's not the question you're asking, please let me know.
If you have a webapp (say a todo app) that you deploy for multiple customers, and each customer is a tenant in FusionAuth, the todo app could know based on the domain name (foo.todo.com or bar.todo.com) or path (todo.com/foo or todo.com/bar) it is deployed to which FusionAuth tenant id (foo's or bar's) to pass along to FusionAuth. Here's a relevant forum post: https://fusionauth.io/community/forum/topic/19/can-different-tenants-have-their-own-custom-domains-self-hosted-community-edition
If there's no differentiation at the URL level, you could store the tenant id on a group or user table in the database.
It's also worth noting that in the default settings for FusionAuth, the client id is the application id. An application id ties a login session to a particular tenant, since every FusionAuth application belongs to only one FusionAuth tenant (though a tenant can have multiple FusionAuth applications).
Related
I'm trying to better understand how to make use of OIDC/OAuth in securing a restful API, but I keep getting lost in terminology. Also when I research this question most of the answers are for Single Page Apps, so for purposes of this question assume the API will not be used for an SPA.
Assumptions:
Customers will access a restful API to interact with <Service>.
It is expected that customers will create automated scripts, or custom application in their own system to call the API.
Once setup it is not expected that there will be a real person who can provide credentials every time the API is called.
<Service> uses a 3rd party IDP to store and manage users.
3rd part IDP implements OIDC/Oauth and that is how it should be integrated into <Service>
Questions:
What OIDC/OAuth flow should be used in this situation?
What credentials should be provided to the customer? client-id/client-secret or something else?
What tokens can/should be used to communicate information about the "user"? E.g. Who they are/what they can do.
How should those tokens be validated?
Can you point me to any good diagrams/resources that explain this specific use case?
Am I missing anything important in the workflow?
It sounds like these are the requirements, if I am not misunderstanding you. The solution contains not just your own code and is more of a data modelling question than an OAuth one.
R1: Your company provides an API to business partners
R2. Business partners call it from their own applications, which they can develop however they see fit
R3. User authentication will be managed by each business partner, resulting in a unique ID per user
R4. You need to map these user IDs to users + resources in your own system
OAUTH
Partner applications should use the client credentials flow to get an access token to call the API. Each business partner would use a different credential for their set of users.
Using your own IDP to store users does not seem to make sense, since you do not seem to have an authentication relationship with the actual end users.
Access tokens issued to business partners would not be user specific by default. It is possible that a custom claim to identify the user could be included in access tokens - this would have to be developed in a custom manner such as via a custom header, since it is not part of the client credentials flow.
Access tokens would be verified in a standard OAuth manner to identify the partner - and possibly the end user.
DATA
Model users in your own system to have these fields, then store resources (such as orders) mapped against the User ID:
User ID (your generated value)
Partner ID (company the user is from)
External User ID (an ID that is easy for partners to supply)
Typically each partner would also have an entry in one of your database tables that includes a Client ID, name etc.
If you can't include a custom User ID claim in access tokens, partners have to tell you what user they are operating on when they call the API, supplying the external user ID:
POST /users/2569/orders
Your API authorization needs to ensure that calls from Partner A cannot access any resources from Partner B. In the above data you have all the fields you need to enable this.
SUMMARY
So it feels like you need to define the interface for your own APIs, based on how they will be called from the back end of partner apps. Hopefully the above hints help with this.
I work for a company where we give customer (hundreds/thousands of users) access to 2 sites. One owned by a 3rd party SaaS and one owned by us.
Customers spend alot of time registering for both sites and we also spend alot of time removing accounts when customers no longer need access.
I would like users to register for Site A. After successful authentication; a user can click on a link within the site to access Site B but without the user entering credentials.
I want Site A identity to be used to access site B and its resources. I do not need site B resources to be presented on Site A site, but simply allow users to access site B if already authenticated to site A.
Users may have different roles on site B.
What is my best option? Oauth2 sounds like a good option. But will it satisfy my requirement above?
Who will manage the authorisation server? I presume Site B?
Thank you.
Two main options:
OLD TECH WITH COOKIES
Perhaps the cheapest option is to use hosting domains and have 2 apps like this:
mail.google.com
drive.google.com
Use a cookie issued to the parent domain, google.com
Cookie identifies user, to provide a user id
Rights are looked up in each app from the user id
OAUTH2 AND OPENID CONNECT
This is the option for modern apps and they are usually used together, due to being web, mobile and API friendly.
It is a big job though, including user migration, and usually involves giving users a new password. So it needs to be something your company are prepared to invest in.
The Authorization Server (AS) becomes a shared central resource and it is common to use a Cloud Provider to ensure high availability.
RELATED RESOURCES OF MINE
Initial Code Sample with Cloud AS
User Migration Blog Post
I have a single realm with 3 single-page applications and a shared backend. I want to restrict the access to one of the SPAs so that users without a specific role can't log in.
But once you create a user in the realm, he can log in to every SPA client. I can restrict the endpoints of the backend but I don't want to programmatically reject the user in the specific SPA but automatically on the login page.
I tried to use client roles which don't seem to have an effect in this case. The only solution I have found so far is to create separate realms which I think is conceptually the correct way but unfortunately brings up some practical issues, e.g. the administrators of one realm must be able to manage (CRUD) users of another realm which seems fairly unintuitive.
users without a specific role can't log in - it isn't good requirement. How system will known if user has a specific role without log in (authentication)? Keycloak provides Open ID Connect SSO protocol, which is designated for authentication. After successful OIDC authentication is token generated, which may contains also user role. So only then authorization can be applied. So let's change requirement to: users without a specific role can't access SPA, which better fits into OIDC concept.
The mature OIDC SPA libraries offer authorization guard (name can differs, it is some kind of post login function), where authorization can be implemented. Authorization requires to have a specific role in the token usually, otherwise user is redirected to the custom route, e.g./unauthorized. That's the page, where you can say a reason for denying access. Common use case is also customization of the app based on the user roles. For example users with admin role will see more items in the menu than standard users - that's also kind of authorization. Random example of SPA library with authorization guard (I'm not saying that's a best implementation) - https://github.com/damienbod/angular-auth-oidc-client/issues/441
Keep in mind that SPA is not "secure" - user may tamper code/data in the browser, so in theory user may skip any authorization in the browser. He may get access to SPA, so it's is important to have proper authorization also on the backend (API) side. Attacker may have an access to SPA, but it will be useless if API denies his requests.
BTW: You can find hackish advices on the internet how to add authorization to the Keycloak client with custom scripting (e.g. custom scripted mapper, which will test role presence). That is terrible architecture approach - it is solving authorization in the authentication process. It won't be clear why user can't log in - if it is because credentials are wrong or because something requires some role in the authentication process.
You should indeed not create multiple realms, since that is besides the point of SSO systems. Two approaches are possible in your - presumably - OAuth 2.0 based setup:
restrict access at the so-called Resource Server i.e your backend
use a per-SPA "scope" for each SPA that is sent in the authentication request
The first is architecturally sound but perhaps less preferred in some use cases as you seem to indicate. The second approach is something that OAuth 2.0 scopes were designed for. However, due to the nature of SPAs it is considered less secure since easier to spoof.
I was able to restrict users access to application using following approach:
I've created to clients in my default realm (master) i called my clients test_client1 and test_client2 both of them are OIDC clients with confidential access by secret
I've created a role for each of them, i.e. i have role test_client1_login_role for test_client1 and test_client2_login_role for test_client2.
I've created a two users - user1 and user2 and assign them to client 1 and client2 role. But to restrict access to client1 i have to delete default roles:
That did the trick, when i am logging with user2 i see test_client2 and not test_client1 as available application:
But i did n't delete roles from user1 and therefore i could see both clients when i am log in with user1:
Therefore you should use different clients for your applications, assign to each of a client specific role and remove from users default roles and add one releted to specific application.
I am developing a python app running on embedded linux to access office365 calendar via the EWS interface. I plan on using impersonation to access data.
I have registered my app with azure AD and retrieved the endpoints which contain a tenant id. But I have learned that using the common endpoint seems to work just fine in refreshing the access token.
what are the advantages or limitations in using the tenant id instead of just using common?
Take a look at http://www.cloudidentity.com/blog/2014/08/26/the-common-endpoint-walks-like-a-tenant-talks-like-a-tenant-but-is-not-a-tenant/. The common endpoint does late binding to the tenant based on the users login details. The article does add "For line of business applications you do NOT want to late bind the tenant, in fact you want to ensure that the caller comes from your specific tenant and no other! In that case, use of common is not appropriate."
I want to allow users of a SaaS based, asp.net MVC, Multi-tenant DB to login using their social media credentials (FB, TW, G+, etc).
In addition to the social media account validation, how can we determine which tenant or users within a tenant in the DB to validate against? I presume some flavor of Asp.Net Identity should be used to bridge the gap??
I have implemented a custom OAuth server that inturn handles the pluggability of the various social media login modes via OWIN middlewares.
However, when you wanted to have a simplified approach, you can choose to go with Windows Azure Access Control service which can enable you to identify the tenant via their URI.
In that case, you can infer the tenant name or tenant unique value from the URI [like a subdomain part] of the URI.Host.
You may refer here / here / here.
In case you wanted to build your own model, you will have to capture the tenant information via either a unique URI from where the tenant comes from or from getting a tenant unique value from the UI or as a query string from a URI [Rare & least secure case].
The points worth pondering upon will be
Time
Cost [Azure does not come for free]
Customization aspects
Please share your thoughts on the points above.