I'm working on a password management system which stores the passwords of a bunch of services (gmail, bank of america account, youtube etc). The user will be able to launch each of these services by logging into my application. The application will then POST the username and password associated with that service to that service's login url in a new tab and you will be immediately logged in. My question is, this method exposes the actual password of the user to the client side (since I'm creating a form with username and password, in plain text, as hidden fields and calling form.submit). I'm wondering is there any other method by which this can be achieved? How do all the password management sites work? Your help is appreciated.
Do it server side, what else can I say? Anyway, I can only see this as a learning experience, not something that would eventually go into production. cUrl could be a good start. Why do you use form.submit anyway?
This is called "formfill" in terms of access management terminology, if you are thinking about access gateway (http). If you are thinking about browser plugin, have a look at the firefox autofill plugin. And which finally reduces to single sign-on.
Single sign-on are done different ways,-
some servers uses active directory to store all the passwords and later access using the master password , i.e. the active directory password of that user to access his credentials.
Some uses SAML
Some uses e-directory
Whatever you use, if it is server-side application (e.g. Appache supports formfill), it parses all the forms based on form name or resource path and fills credentials based on the authenticated session from the user.
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
I am creating a login page with an authentication using LDAP. I could see LDAP3 packages for flask with login forms as well. I am looking for a form where the developer of the portal(say me or anyone in our team) should not be able to add any print statements and sniff the username and password when someone log in...
The flask form is exposing the password variable as a plain string. Even if it doesn't expose , it is possible to put a print statement in the flask_form validate function.
Is there any option available like the form is bundled as binary or c-python module where the developer has no option to sniff the credentials at all..
If not possible or no options available as they know off, any other framework like django helps for these usecase?
By design, server-side LDAP authentication requires the server receive the username & password from the user and relay that information to the LDAP server. This means a developer could insert a line that logs all credentials out somewhere, grab the passwords from process traces, dump memory, etc. If you don't want any of the developers or system administrators to have access to user passwords, use some type of federated authentication instead of LDAP.
In a federated authentication scheme, the user auths against some other source (e.g. ADFS) and your app checks a token that essentially says "this trusted other auth source says the person is Lisa".
Everything I'm reading shows that in order for an application to use onedrive, it has to do the oauth2 thing to get credentials. But what if you're a batch process and don't have a web interface for your users.
Google's API has a special type of account called a service account where once you set it up, you can control access to everything from that one account, no need to interact with users. Does such a thing exist for onedrive?
App-only authentication doesn't require the user be prompted for credentials but it also isn't supported in 100% of scenarios. For example, the APIs need a user principle for creating special folders and resolving a user's personal site. Also, it is only supported for OneDrive for Business, not Consumer. Consumer always requires the user be prompted for initial authentication.
Another option would be to spin up a web service of some sort that handles initial user authentication, ie. a sign up page. With that, you can retrieve a refresh token for offline authentication and store it for the user. Every authentication from then on can be done using the refresh tokens, which doesn't require a user prompt.
I finally found this. It's the same basic idea as google's service account, but I think it's harder to use. But at least the concept is supported.
http://blogs.msdn.com/b/exchangedev/archive/2015/01/21/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx
After logging in and validating the users login credential a website has to somehow map each request on the site to a logged in user. I only did user management with various framework so far and I have some question on how this is done. As I want to write a thin website which itself acts as a client to piece of software with its own user management I cannot just use a framework here.
As far as I can follow a website can do one of two things:
use http authentication, which is a huge pain in the neck, as logging users out is unreliable and the UI is generally ugly;
use cookies with some secret per user.
What I struggle to understand is the "Remember me" check boxes on login forms. Reading up on the mostly not very technical explanations those check boxes make the browser save a cookie. Where I come to the question:
Don't all form-based-login using websites store a cookie to identify a client? If not, how does the server match a request with those clients?
Yes they all do. "Remember me" is saving settings for a user, not identifying the user. It's a cookie keeping them logged in or pre-inserting their user name into the form (depending on how its built.)
I am trying to learn CAS and I have the cas-server-3.4.10 running in tomcat6 by just moving the war into the webapp.. I am following the install.txt which show me to use NetID for the user name and password and it works but where is the user information?
If you are just using the standard WAR file without making any changes, the default authentication handlers works such that the userId must be the same as the password you put in, so that you can login. This is just a sample and should never really be used in production.
Your user credential store is usually maintained elsewhere, typically inside an LDAP or ActiveDirectory instance. You'll then need to configure the config file with the right authentication handler that received the connection info to that instance and validates user accounts.
CAS is not responsible for user account management, etc. It works with existing solutions that provide a remedy for that need.