I am considering enabling multiple tenancy on an existing app that uses Firebase Authentication, having read this https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication
What I'm not clear on and therefore worried about, is what happens to my existing app users once I add a new tenant? Will they be unable to login unless I migrate them to some "default" tenant?
I haven't found any assurance or explanation in the docs, so maybe its ok, but I don't want to click that button unless I am sure. And is there any way to back out of enabling multi tenancy in the event of a disaster?
So in the absence of any reassurance, I just went ahead and clicked the button. Nothing bad happened to my existing users. They were migrated from Firebase authentication to GCP Identify Platform, under the context of the project, which runs along side tenants it seems.
Then I was free to make another tenant, which formed an entirely separate space to configure providers and house user identity.
Related
What is the best way to restrict the scope of a connected app to a set of objects? My current solution is to use the Manage user data via APIs scope but that still grants more access than required.
A solution I see frequently is to create a user with a restricted profile and connect with that user but then you lose context of actions made by users in the connected app so this solution doesn't work
Tricky, you typically don't. (consider posting on https://salesforce.stackexchange.com/, there might be a clever way I didn't think of).
You can flip the connected app from "all users can self authorise" to "admin-approved users are preauthorised" and then allow only certain profiles / permission sets to use the app. But the bulk of it is "just" enabling the connection via API and cutting it to say Chatter only or OpenId identifiers. And that's already an improvement compared to SOAP APIs where you don't have scopes and the app can completely impersonate the user, do everything they can do in UI.
Profiles/permission sets/sharing rules are "the" way even in not immediately obvious situations like Lighting Connect Salesforce to Salesforce or Named Credentials access to another org.
If you can't restrict the visibility with profiles and access to all tables user can see is not acceptable...
you could create series of Apex classes exposing certain queries, updates etc and grant profile access to these classes - but without full api access? You could even let them pass any SOQL (evil) but use with sharing, WITH SECURITY_ENFORCED, stripInaccessible + custom restriction on tables before returning results
you could look into https://developer.salesforce.com/docs/atlas.en-us.238.0.apexref.meta/apexref/apex_class_Auth_ConnectedAppPlugin.htm although I suspect it's run only on connect, not on every request. So at best you could deny access if user has right to see some sensitive data, not great
if there are few objects you need to block updates if done via app - Quiddity might be the way to go. Throw error in a trigger if action started from REST context?
give the Transaction Security trailhead a go. If it looks promising (there's way to check "application" and "queried entities" according to this) - might be a solution. You'll likely have to cough up $ though, last time I checked the cool bits of event monitoring & transaction security were hidden behind an extra paid addon (standalone or bundled with platform encryption and Field Audit Track into Salesforce Shield solution)
2 logins? dedicated user for querying stuff but inserts/updates running as your end user?
The "Two Factor" requirement is configured per user. If we have multiple applications, how do we achieve that
for application A (e.g. a webapp) 2FA is required
but for application B (e.g. a native app), for the same user, 2FA is not required (never, not even for the first time it is used)?
I'm aware of the trustComputer attribute but I don't think it helps for this problem.
Two Factor is at the User level in FusionAuth. This is by design since if the user has selected to protect their account, then they should be forced to provide their additional factor regardless of the Application they are logging into.
There isn't currently a way to change this behavior and we would need to understand the use case in detail as well as any security issues with allowing specific Applications to bypass two-factor authentication.
You can open a feature request on the FusionAuth GitHub issue tracker here: https://github.com/FusionAuth/fusionauth-issues if you want. Please provide as much detail about the use case and why some Applications allow two-factor while others don't. This will help the FusionAuth team assess the implications of adding this feature.
I am working on a project that allows a user to create a user to create app keys or secrets so that specific services can be used by external clients. A user can create multiple secrets that they can choose to use across multiple clients.
For this I am planning to create a decoupled auth server that will use identityserver4.
What really holding me back is that I am not sure whether or not I should create an API layer at the auth server. The reason I am considering API at auth server is so that I can create sort of an admin portal client that will give the users a front-end for creating, renewing, and accessing their app keys/secrets. Even the admin portal is going to be a de-coupled angular application.
There are two things that are holding me back at the moment:
I am not sure if it's a good or safe idea to serve this data via
an api layer. From what I understand, identityserver will not be able to provide functionality that allows me to access a list of a user's clients through an endpoint but please correct me if I'm wrong and there's a better way to approach this.
I know we can easily create new clients and persist it into the database with identityserver4 and I am planning to use ClientCredentials grant types for user clients, but is there a link at the database and identity level between a user and a client? Or will I need to create that functionality by myself?
So far I've looked but I have not bee able to find examples that are similar to my situation with identityserver4
Sorry for the noob question, I am just getting into identityserver and web security in general so many of these concepts are still very new to me.
For number 1, I would say yes you can create an API layer to server data. If you check the IdenttiyServer4 AdminUI, Rock Solid has also use the admin API behind the UI. But you must consider encryption, TLS and other security mechanism to keep this safe.
AFIK for number 2, there are no links at identity level between a user and a client. You have to create that by yourselves.
Basically, you need a system that supports Multitenancy. I have achieved that by adding a TenantId field in the AspNetIdentity user table. And also added the tenant Id to claim list.
Please do not hesitate to correct me if i am wrong.
I'm a developer at a company that has an application that is built with PHP and MySQL. We have about 300 users that have their passwords hashed with bcrypt and stored in the users table. We're looking to rebuild the application with Angular and Firebase.
My question is, how to I migrate these users over Firebase and use Firebase Auth. It's easy to migrate the profile info over, but I want to be sure that the user can still use the same email/password when they login to the new application.
Here are some approaches that I've thought of. All of these are terrible in my opinion.
A) Create a custom auth system that uses bcrypt, and then just copy the hash over. This isn't what I want because I don't want to maintain a custom auth solution.
B) Every time a user logs into the old system, grab their password from the login field, store it in plaintext, then manually create each user in Firebase with their email/password. This would require 100% of users to login before we switch to the new app. That is unlikely. Also this is obviously a breach of privacy. I'm sure it breaks some sort of law or standard. But it works and it's a last resort option.
C) Every time the user logs in to the old system, send the email/password in plaintext to a script that auto-creates a new Firebase user with the same user/email. This would require 100% of users to login before we switch to the new app. That is unlikely. It's also harder to build than option B.
None of theses options look very good. They all have downsides. Is there a better option? If not, between B and C, which is most legal/ethical? Option B tempts me because it's super simple, but I don't want to break any laws or lose the trust of my companies clients.
[From Firebase Authentication team]
Firebase has a better solution. Firebase Authentication service has the capability to batch import password hashes of your existing users, for well known hash algorithms (hmac-sha256, bcrypt, scrypt etc.). End users just sign with their existing passwords, and your app will receive a Firebase token containing the same user_id you uploaded. None of the option A/B/C is needed.
[Update 11/19] The Firebase command line tool 3.2.0 supports importing bcrypt hashed passwords to Firebase Authentication service.
Disclosure: I work at Auth0.
Disclaimer: If you really set your mind on using Firebase from a practical point of view this might not help you as it focuses on what Auth0 provides to solve problems similar to the one you described. However, from a theoretical point of view this might help you so I deemed it worthwhile to share.
Enough with the legal stuff...
Check this guide for a fully detailed view on how Auth0 supports migrating users from your custom store to a hosted one.
... automatic migration of users to Auth0 from a custom database connection. This feature adds your users to the Auth0 database one-at-a-time as each logs in and avoids asking your users to reset their passwords all at the same time.
The approach would be similar to your option C, but the only thing that would need to stay from the old system would be the database. Everyone would start using the new application and the login would happen transparently for the users. Depending on the API's made available by Firebase, you could most likely implement something similar and that would be my recommendation.
Additionally, you should not even consider any process that includes manual steps and has to deal with plain text passwords.
A final note, excellent decision on rebuilding your app to use an external authentication service, even if it's not Auth0. :)
Authentication is a hard problem and wish more application developers stopped wasting time with issues totally unrelated to the business problems that their applications solve.
The Firebase CLI very recently added an auth:import command that allows you to import an existing user database into Firebase Auth from CSV or JSON.
I wish to create a functionality that is very similar to facebook or pokerstars if you have used them before. Basically the apps require the user to login and their information can be accessed from both browsers and native and web apps.
How can I go about achieving this? Please advice on what services to research on to accomplish this. To my current understanding. I would be creating the website in html and php and creating a webservice using RESTful protocols and hosting them on amazon aws servers. I can then connect to these servers in the native apps? I am not very clear on how the native apps will interact with the servers
If you know of any particular protocol or a better server hosting service please let me know.
If I'm interpreting your question correctly, you are looking for something like this:
The user starts either your browser app or your native app (perhaps a mobile app)
Since the user does not have an account yet, you present them with the appropriate dialog to create said account.
You then ask the "Identity Service" to create a profile for that user
The identity service returns a token for access
This is something we do in the mobile network industry all the time. Technically, we have TAC/ACS or HSS profile services, but in either case, it's the same thing -- a dedicated service and network process that:
Accepts connections from various clients (web, mobile, desktop...)
Has various primitives along the database CRUD (Create, Read, Update, Delete) model
Answers requests the database
If you want a pre-configured solution, you could just use any networked database with a RESTstyle connector for example (MongoDB maybe?) But you could also just through this in a process that talks to a NoSQL or SQLLite database. The end result is the same.
For commercial solutions, I might like at OpenStack as you can run your code on it and they have identity brokers you might be able to CoOpt.
Personally, I'd just have a datastore running on a cloud somewhere like Amazon's EC2 which answers RESTful requests such as:
Create a user with a given profile set, return a unique token
Delete a user given a token
Update elements of the profile for a given token
I'm leaving out the necessary things like security here, but you get the idea.
This also has the advantage that you can have a single identity service for all of your applications/application services. The specifics for a given application element are just sub-fields in the profile. This gives you, not only a common identity broker for web, desktop and mobile, but a single-sign-on for all your applications. The user signs in once and is authenticated for everything you have. Moving from site to site, now just became seamless.
Lastly, you place your identity management, backup, security token management, etc OUTSIDE of your application. If you later want to add Google Authenticator for second-factor authentication, you don't have to add it to every application you have.
I should also add that you don't want to keep the identity database on the direct internet connection point. Someone could make your life difficult and get ahold it later on. Rather, you want your identity server to have a private link to it. Then do something like this:
When the account is created, don't store passwords, store hashes -- much safer
Have your application (web or otherwise) compute a key as the login
In this case, the user might enter a username and password, but the application or website would convert it into a token. THAT is what you send across.
Next, using that token (and suitable security magic), use THAT as the owner key
Send that key to the datastore and retrieve any needed values
Encrypt them back into a blob with the token
Send the block
THe application decrypts the blob to get at values
Why do we do this?
First, if someone were to try to get at your identity database, there's nothing useful. It contains only opaque tokens for logins, and blobs of encrypted data. Go ahead -- take the database. We don't care.
Second, sniffing the transport gets an attacker nothing -- again, it's all encrypted blobs.
This means later on, when you have five applications using the broker, and someone hacks the network and steals the database, you don't care, because your users never gave out logins and passwords in the first place, and even if they did, the data itself is garbage to anyone without the user key.
Does this help?