the company I work for has 3 environments (development, staging and production) and 3 types of users (consumer, employee and partners)
Should we create 9 tenants?
dev/consumer
dev/employee
dev/partners
stg/consumer
stg/employee
stg/partners
prod/consumer
prod/employee
prod/partners
Hey there Rodolfo I work with the Auth0 Community and it's recommended to create separate tenants per each environment.
Development, Test, QA environments are easy to setup in Auth0. Simply
create a new tenant for each to guarantee the maximum isolation
between these environments. You can easily switch between tenants
using the tenant chooser from the top right menu on the dashboard. You
can also configure different administrators for each.
https://auth0.com/docs/dev-lifecycle/setting-up-env
Thanks, Jim!
Related
For example, suppose I am making a restaurant app, which API should I use to let owners post their own restaurant and then manage it(title, available tables, foods etc.) from a dashboard? Can this be done with Sanity or Firebase?
With firebase yeah - I had done something similar before. You'll manage your users (restaurant owners) within Firebase. You can have a "Role" column that would indicate permissions for that user on your app.
So for example, you may have an admin, manager and general user. Admins will have read/write access to everything whilst manager some of the content and general users read only.
How to create users: https://firebase.google.com/docs/auth/web/manage-users
How to set 'custom properties', in your case - it can be the role: https://firebase.google.com/docs/analytics/user-properties?platform=android
Firestore is a document based, non SQL database and free to a certain point: https://firebase.google.com/docs/firestore
There many different ways this can be achieved, this would just be an example that comes to mind - and it would work for small scale projects.
If the app gets a lot of traffic and users, I'd switch to AWS.
If I have multiple Atlassian tools integrated with Crowd, i.e Jira, Confluence, Bamboo, etc., is it possible to grant a user access to Jira and not to Confluence or vice versa?
This can be done by the use of Groups. So, for example, you could have a jira-users group and a confluence-users group. Some users maybe members of both but other users may only be members of one and not the other.
The Managing Groups documentation for Crowd should help setting up the groups and adding users to them.
Specifying which Groups can access an Application details how to setup the restrictions you require per application.
Please note, that both these tasks require admin access to the Crowd Administration Console.
I'm exploring the WSO2 Identity server as a possible solution for a requirement we have.
We manage a lot of accounts, and every account has it's own admin users, users & roles.
We have a set of available permissions which is shared between all accounts, and (permissible) users can create new users, roles, attach roles to users etc..
But, the Users / Roles must be separated between the different accounts.
Also, accounts can be created / modified during run time.
What is the best practice to achieve this using the WSO2 IS? Maintaining User store per account? Using multi-tenancy?
I'm all over the WSO2 docs and can't seem to find a recommended solution to this requirement.
Thanks!
AFAIK it is better to go with multi tenancy. There you can create multiple tenants for each group and have an admin user/users/permission/roles specific to that particular group
We have a large multi tenant business application and we want to know how Entity Framework and Authentication will fit in this design; i mean i need samples on how to use Entity Framework in this design and how authentication will be done; i see Dynamics Crm and sharepoint use Configuration(Master) Database and different databases for each tenant; how the users will be authenticated and saved;when i investigate dynamics crm configuration database, i see it contains users table; also, the tenant database contains Users table and i don't know the difference
Your question is broad and may require a lot of detail to go into. I would like to give you a simple overview.
The Entity Framework & OWIN Middleware's are one way of easing in the development effort. You choose EF when you ONLY have a object model that is similar to that of your database.
The advent of OWIN middlewares help you to easily integrate with a wide variety of authentication mechanism like Google, Facebook, Azure Active Directory etc...
Additionally, in addition to using OWIN, you will still require to build a logic around the user and tenant management systems. There will be a tenant table that contains the metadata about your tenant's [customer's].
There will be a user table that will contain your user's against tenant's. Here, each row can be identified against a tenant using tenant identifier or you can opt to use a separate table for each tenant.
The single database model is the one which is shared by all the tenant's and is belonging to the Level 4 of Multi-tenancy.
You should decide based your business specific use case whether you need to support a shared database or a dedicated database per tenant.
With OWIN, I have also written middlewares that can talk to any OAuth2 enabled IDP and get back the user into the system. It is upto the business usecases which drive the level of customization and depth of integration required and the technologies just help us achieve the same.
Please share some more specific questions or your views to discuss further
I am working on a system architecture for a fund/pension manager. We are providing two ASP.NET MVC web applications; one to allow members of the pension fund to login and check their balances, manage their investment, etc and another to allow employers to make contributions to the fund on the employees (members) behalf. There are also internal applications delivered via the intranet.
We have been considering using Active Directory for storing, authentication/authorisation of not just the internal users (who are already using AD for logging into the domain and resource authorisation) but for the member and employer user accounts. The member and employer user accounts would be located in a different hierarchy (maybe even a different AD instance?) to the internal users.
However I am wondering if this is the best use-case for AD... given AD is such an 'internal' resource, should it be used to hold auth details for 'external' users (the alternative being a USERS table in a database)?
The benefits are: AD is designed and optimised for holding this sort of data, ASP.NET apps integrate with AD authorisation easily, there possibly are existing tools for working with the data (password resets, etc).
What are the risks?
I would recommend against a hybrid of internal and external users. Speaking from experience it opens a lot of security headaches. It might be better to create separate authentication systems, one that uses AD directly against the internal domain and another that uses an ADAM directory designed simply to hold external users. (i.e. - internal users should be authenticated using NTLM with the AD to ensure a kerberos encrypted login, while forms would be usable for the ADAM instance).
AD is very easy to integrate though, and if direct integration is undesirable due to the networking lumps, you can always attempt an LDAP:// to achieve the same authentication results.
I think your biggest risk is that AD would not scale to the amount of users you might have from an Internet app. I would use the Membership provider, unless you are trying to achieve SSO with internal and external accounts.