I am trying out a sample hyperledger fabric app. I am thinking to develop a web app that can communicate with fabric chaincode and execute chaincode functions. But inorder to uniquely identify a user, the certificate is required. How can I achieve a user login mechanism in my web app (for example with username, password) such that it will identify the user who logged in and is calling the function.
Hello #Mohamed Noushad
It is very simple
As we know once we register a user and enroll we will get a private key and a certificate to us. It will be difficult to manage the keys by the users
So, traditional users are more comfortable with usernames and passwords rather thank keys. So, Create a database on top of user keys. username, user
user is for fabric and username is for your database. Or you can use the username for both
You handle the keys and the user needs to authenticate to prove that the set of keys belongs to him. Once the user authenticates with creds in the database using a normal username and password then you allow him to interact with fabric with the key enabled by you on behalf of the user.
Certificates can be stored in three different ways
local kvs (file system)
couch dB kvs
Hardware wallets (HSM)
This is just one suggestion. We can do (n) No of ways. just think!!
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
Problem Statement:
I want to solve the user authentication on Android applications using the FIDO2 protocol(by providing an SDK), without doing multiple registration ceremonies for different applications on the same device.
For example, If a user has been Registered(generated Public-Private key pair) in an Android application A, he/she shall not be required to Registered in an Android application B(Given App A and App B are on the same device).
What could be the possible Solutions(as per my knowledge):-
A common SDK integrated with application A and B to provide authentication.
Separate Authentication App.
I want to go forward with Solution 1 as Solution 2 might not be desirable because it needs an extra step of downloading an extra app(Authentication App).
What am I able to achieve right now:-
We are able to do passwordless authentication of a user for app A and app B by maintaining separate private keys for app A and app B .
In the above diagram:-
User XYZ logs-in to App A and registers himself with app A on this device.
During the registration step a Public-private key pair is generated by the authenticator.
PrivateKey_1(PrivateKey) gets created and is stored in the Keystore and PublicKey_1(PublicKey) gets created and is shared with the server.
Let's say now that User XYZ wants to login to the app B.
Same process gets repeated for user XYZ to register him with app B.
In this process, A PrivateKey_2 gets created and is stored in the Keystore and PublicKey_2 gets created and is shared with the server.
So in above scenario User XYZ is able to authenticate on App A and App B using private key PrivateKey_1 and PrivateKey_2 respectively.
I want to know the feasibility of the following Scenario?
I want to do passwordless authentication of user XYZ for app A and app B, where applications(app A and app B) can use the same credentials (public and private key pair ) and do not need to perform a repeated registration ceremony(creating public and private key) for the same user on the same device for multiple applications sharing the common SDK(app A and app B).
In the above diagram:-
User XYZ logs-in to App A and registers himself with app A on this device.
In this process, a PrivateKey_1 gets created and is stored in the Keystore and
PublicKey_1 gets created and is shared with the server.
User XYZ wants to login to the app B.
App B should be able to verify user XYZ using the previously generated
credentials(by app A).
Is this even possible? Is there any gap in my understanding?
Any Suggestion and help is really appreciable :) :)
FIDO2 credentials can be reused wherever the API is available so long as you reference the same RP ID whenever you attempt authentication. FIDO credentials are bound to a unique RP ID, and as long as you can prove ownership of an RP ID then you'll be able to request authentication with any credentials associated to that same RP ID.
In the case of Android, you'll be able to auth across apps so long as both apps are connected to a single website and its unique RP ID. To connect your app to a website, check out the FIDO2 API for Android docs, particularly its section on Interoperability with your website. It links to Google's page for setting up Digital Asset Links on your site so that you can prove ownership of an RP ID and use credentials associated with it for authentication across apps.
Once your apps and website are linked and the user has registered in one app you should then be able to use Fido2ApiClient.getSignPendingIntent() to authenticate in your second app so long as you specify your site's RP ID (the same one specified during registration) as the rpId in the PublicKeyCredentialRequestOptions you pass to the method.
P.S. What's nice about all of this is that credentials you register using Fido2ApiClient (or any equivalent API on other platforms for that matter) in a native app can later be used to log into your website using the WebAuthn API in the browser; you just need to reference the same RP ID in the PublicKeyCredentialRequestOptions you pass to WebAuthn's navigator.credentials.get()!
One of the main benefits of FIDO2 is that it prevents man-in-the-middle attacks where an attacker is trying to impersonate a genuine replying party. The FIDO2 key will only respond to the RP for which the private key is registered. Sharing authn across multiple RPs would break this model. I don't know what is possible on an Android device but I would have thought you would need some form of authentication broker (an IdP) which you auth to with the Key and it is responsible for proving auth to the apps.
Are these accounts registered on the same service? Reading the Android FIDO2 API Interoperability with your website section, it seems possible to host https://example.com/.well-known/assetlinks.json with multiple Android apps listed.
I saw your problem statement and I think you should use SAWO Labs API for solving the authentication part as it is very easy to use. You can use one API key in multiple applications to use the authentication and also this API has a trust feature where you have to authenticate from each application where the same API is used for one time and you will no longer need authentication every time. SAWO Labs API is a passwordless user authentication tool.
You can know more about the SAWO Labs API from the link given below:
https://sawolabs.com/
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.
I was to keep user logged in (user shouldn't enter username/password every time he uses the app) like in Facebook & Twitter.
I've gone through question & the only way I found is to save username & password then perform login every time the user opens the app
Does Worklight/MobileFirst have a way to keep user logged in?
There are other Worklight/MobileFirst features that you may be interested in looking into...
Device SSO
http://www-01.ibm.com/support/knowledgecenter/?lang=en#!/SSHS8R_6.3.0/com.ibm.worklight.dev.doc/devref/c_device_single_sign_on.html
Single sign-on (SSO) enables users to access multiple resources (that is, applications and adapter procedures) by authenticating only once.
SSO session lasts as long as the session timeout period configured (default 10 minutes).
User certificate authentication
http://www-01.ibm.com/support/knowledgecenter/?lang=en#!/SSHS8R_6.3.0/com.ibm.worklight.monitor.doc/monitor/c_user_CA.html
Very first time you're asked to authenticate using your authentication realm of choice. At this time your device is enrolled and an x509 certificate is saved on your device.
Every request after that uses an x509 certificate stored on device... so authentication is seamless to the user.
You're asked to reauthenticate only after x509 certificate expires, or is revoked.
Requires a PKI (to manage certificates). An embedded PKI is provided only for dev/test purposes.
Certificate can be associated with a single app or a family of applications (signed by same identity and belonging to the same group).
JSONStore
http://www-01.ibm.com/support/knowledgecenter/?lang=en#!/SSHS8R_6.3.0/com.ibm.worklight.dev.doc/devref/c_jsonstore.html
JSONStore is a lightweight, document-oriented storage system that is included as a feature of IBM® MobileFirst Platform Foundation, and enables persistent storage of JSON documents.,
You can store encrypted passwords, but you would need to save some sort of PIN as the password for the store in order to save the password correctly.
Simple Data Sharing
http://www-01.ibm.com/support/knowledgecenter/?lang=en#!/SSHS8R_6.3.0/com.ibm.worklight.dev.doc/devref/c_simple_data_sharing.html
You can store simple data like user id/passwords using simple data sharing. The data persists after the app is shut down. You can even share this with other applications in the same family (signed by same identity and belonging to the same group.
Sounds like you're looking for a "remember me"-like functionality.
IBM Worklight does not provide this ability built-in. You need to implement it.
You can review past questions about this, like this one: How to achieve "Remember Me" functionality for both local and remote login pages?
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/