In the software I'm writing, you login to your account for a piece of desktop software, and then many users use the software at a business location (It's not associated with a single user). To allow the desktop software to make requests that aren't directly associated with a single user account, I'm generating a new user behind the scenes for every desktop software link.
I create a user through the Admin SDK that just has a user id (no name, or email, or phone number etc), and give it a custom claim that allows me to differentiate it from the rest of the real user accounts. If the install is unlinked, I delete the user from Firebase.
Is this an acceptable way of using Firebase Auth users? The main thing I'm concerned about is the refresh token expiring or something like that.
Related
I was wondering if it was possible to login to different salesforce environments (Sandboxes, scratch orgs, production env, etc) using either Apex/LWC/Aura (or anything that I can make a quick action to). For example, I have a list of credential records, with the username and password, and I would like to have a login button that creates a separate tab that can automatically redirect to that specific instance and log in.
Currently, if a user wants to login to a particular instance, they have to either go to test.salesforce.com or login.salesforce.com (depending on if it's a sandbox or production) manually, then copy the password and username in. The ideal situation is to have a login button that can do this automatically from the record page where the username and password is located.
I think previously this could have been accomplished through the URL, but salesforce has recently patched this out due to security concerns. Is there another good way to do this?
It sounds like you're trying to solve two specific challenges:
Your users need to be able to manage very high volume of credentials.
You need authentication to survive password resets.
The clear solution, in my mind, is to use the OAuth Web Server flow to execute initial authentication and then store the refresh token that results from this flow. This token survives password resets, and may be used more or less indefinitely to create new access tokens - which users can then use to log in via a frontdoor link.
There's an out-of-the-box tool that does this already: the Salesforce CLI. You can authenticate orgs to its toolchain, name them, and subsequently access them with a single command (sfdx force:org:open). Users that prefer a GUI can access the exact same functions in Visual Studio Code.
If you're hellbent on doing custom development to handle this use case, you can, but you need to be very careful of the security implications. As one example, you could implement an LWC + Apex solution that executed the relevant OAuth flows against orgs and stored the resulting data in an sObject, then allowing users to click a button to generate a new access token and do a one-click login.
But... if you do this, you're storing highly sensitive credentials in an sObject, which can be accessed by your system administrators and potentially other users who have relevant permissions. That data could be exfiltrated from your Salesforce instance by an attacker and misused. There's all kinds of risks involved in storing that kind of credential, especially if any of them unlock orgs that contain PII or customer data.
One of the two best answers for that (the other one being 'pure Apex' and relatively more complex) is using Flow.
"You can use a login flow to customize the login experience and integrate business processes with Salesforce authentication. Common use cases include collecting and updating user data at login, configuring multi-factor authentication, or integrating third-party strong authentication methods.enter image description here"
"You can use login flows to interact with external third-party authentication providers by using an API.
For example, Yubico offers strong authentication using a physical security key called a YubiKey. Yubico also provides an example Apex library and login flow on GitHub. The library supplies Apex classes for validating YubiKey one-time passwords (OTPs). The classes allow Salesforce users to use a YubiKey as a second authentication factor at login. For more information, see yubikey-salesforce-client.
You can also implement a third-party SMS or voice delivery service, like Twilio or TeleSign, to implement an SMS-based multi-factor authentication and identity verification flow. For more information, see Deploy Third-Party SMS-Based Multi-Factor Authentication."
learn more here: enter link description here
A client recently added fingerprint authentication as an alternative form of signing in to their application which stores sensitive data.
Of course, the username and password are verified before allowing fingerprint authentication.
But this and other applications I've tested have had one major flaw which no one seems to talk about. All enrolled fingerprints on the phone are also allowed to have access to user accounts on the application. This means if I add my wife's fingerprint on my phone for some reason or the other, and I allow unlocking my banking application via my fingerprint, My wife is able to sign in freely to my banking application and perform operations on my behalf!
My question is, is there a way to bolster this feature for applications built to run on Android? Can developers integrate selecting what fingerprint (out of the multiple stored on the phone) is actually allowed access to user accounts?
No. The purpose of in-app biometric authentication is to verify that you own the device, not to identify the user because it is assumed that if there are more than one owners, each one of them will have their separate user account created by android Multiple users feature. Multiple users have their own personal space for custom home screens, accounts, apps, settings and more. If the device is enrolled with multiple biometrics under the same account, the device will assume the ownership whoever successfully authenticates with its biometrics.
TL;DR:
We need JWT Auth on an API that is customers specific
Each customer has an API.dll in their own application pool and site on IIS
We need 3rd party BI solutions to be able to securely call the API
We need single users from the customer database to be able to call the API with their existing username and password
Details
At my job we have created a somewhat simple rest API we need authentication for.
The thing is, that the API is not shared between customers. So each customer gets a DLL that is set up to read/write to individual databases.
We would like our API to be usable by 3rdparty systems that our customers use, e.g. BI solutions - as well as user login (the specific users of our system).
Current setup
Each customer has their own: database, application pool, site, desktop app and api.dll (running on IIS)
Customers are free to create any number of users in our desktop application and grant these users varying rights. These users are not centralized across customers. So we have no information about a customers created users (unless we look in their database)
If the customer is self hosted they control the API and the authentication on their server.
If we host their solution we create an active directory user for that customers API and enable basic authentication for that site, granting permission for that single user.
Question
How can auth be set up for this somewhat weird situation, allowing single user authentication as well as allowing 3rd party integrations?
As I understand from my reading we need some kind of hybrid between grant_type: password and grant_type:client_credentials.
As with anything job related, time is a huge factor, but I want the solution to adhere to standards and best practices as closely as possible.
I would like to allow my users to choose from all the available authentication options that Azure Mobile Services provides when signing in but I'm not sure how to link their accounts together if say they choose to authenticate with Facebook the first time and then the next time they run the application they choose a different service.
You have to use a username that upon inserting to your table, you go through as to see if a username of this exists and then link it. Of course this could be a problem if another person wants to login with the same username.
The smartest thing is to retrive some information from the users account so you have some values you can see that are the same. And then you can link them inside.
You could look at this
Windows Azure Multi-Factor Authentication: http://www.windowsazure.com/en-us/documentation/services/multi-factor-authentication/
When using Windows Identity Foundation (WIF) with multiple Security Token Services (STS), is it possible to provision users before they first access the application?
For example, let's say I have a web site called BufferOverrun where users can login and ask/answer questions and I want to support authentication with external Google accounts. When a user first accesses the page, they have to authenticate with their Google account, then they can access the web application. In this scenario, there are two STSes, Google (for identity authentication) and a custom one for my application (for authorization).
How can I assign claims to a user before that users accesses the system?
Since the identity is owned externally to my application, I cannot assign claims directly to that identity (and I wouldn't want to anyway, as they would be application specific). But since the user has not accessed the system, I do not have an internal identity to assign claims to. I see two possible solutions:
Wait for a user to access the system (creating some default application-specific claims), then use some internal provisioning tool to modify those claims as desired.
Have the provisioning tool allow users to manually map a default identity claim (email address, for example) before that identity authenticates by manually typing it in, so that on first access if the identity asserts that claim, a specific set of application claims are granted.
I see a few issues with both 1 and 2. For 1, all users have some implicit access to the system, even if the default application claims allow no functionality. This seems to work great for something like stackoverflow where the initial account has a certain permission set, and as the user uses the systems, new claims are granted. However, this is likely not desirable for all applications. 2 is error prone, as it requires an admin to manually specify a claim.
In both cases above, how do I provision the identity which has access to actually use the provisioning tool (i.e., an admin account)?
For this, I envision that during application installation time, I require a user to authenticate and set the applicaton claims for that identity to be such that they have "administrative" privileges. Is this a good implementation?
Historically (I am now referring to an existing application), the application specifically interfaced with Active Directory only. The way this was handled was that there was a built-in admin account (not affiliated with AD) that allowed the admin user to first login. After authenticating with the admin application, that user could search AD for users/groups and provision them individually. Any user/group not provisioned by the admin would not have access to the system at all. I don't see this paradigm being applicable to using an external STS like Google, etc, so I am trying to conceive an architecture that would enable external STS systems. Retaining the ability to search the STS is desired, though not required. In practice, the two STSes involved would likely both be Active Directory using federated services.
Note: This is similar to this question and this question.
When using Windows Identity Foundation (WIF) with multiple Security Token Services (STS), is it possible to provision users before they first access the application?
The answer is yes, if you have a way of identitfying those users (e.g. their e-mail)
In this scenario, there are two STSes, Google (for identity authentication) and a custom one for my application (for authorization).
This is frequently used, but not necessarilly always the case. If you rely just on Google, then you could simply have the authorization code in the app itself (e.g. "AuthorizationManager" classes, etc). The value of another STS is that it can be a broker for multiple identities (e.g. Google, LiveID, Yahoo!, whatever) and you can do some authorization related transformations.
Since the identity is owned externally to my application, I cannot assign claims directly to that identity (and I wouldn't want to anyway, as they would be application specific).
Why not? You can define a rule that says:
"Anyone authenticated with Google is a 'reader' in App BufferOverrun". You can even say:
"someone#gmail.com is a 'reader' on BufferOverrun", before someone accesses the app.
You can still use the original approach (an out of band admin account for setup). Or you can also "bootstrap" config during provisioning defining which is the claim that will identify admin users.
Take a look at sample "Federation with Multiple Partners and ACS" (sample 7) in http://claimsid.codeplex.com
We do exactly that.