I want login system in my capsule so that i can provide user more recommendation based on their profile of interest. So far, neither I am able to find any document related to login facility nor any example. It would be appreciated if will get any document or example.
Bixby supports logging in through OAuth 2.0, and this is the best way to guide your users through a login flow.
You will need to provide your own service to handle this OAuth flow, as Bixby Developer Center does not offer any web hosting services.
https://bixbydevelopers.com/dev/docs/dev-guide/developers/actions.using-oauth
Also is there a possibility that user can user can use app as a guest
user if no login credentials?
When you define your endpoints, you can define Actions that require OAuth and other Actions that do not require OAuth and the latter ones will define the "guest user" flow that is capable within your capsule prior to logging in.
If you don't need all the features of OAuth, and only need to store a few things between sessions with the same user, you may use the $vivContext.bixbyUserId value as an anonymous, but unique identifier for a user, and store their preferences using that id as a key, in a 3rd party database that you maintain.
I've done this with the "My Brain" capsule, to store quick memories/notes for users, without any requirement that they login or establish an account. I've created a tutorial version of the My Brain capsule that outlines the steps you need to use AWS for this purpose. Please feel free to clone or fork it and customize it for your needs.
Related
I understand how to brand my login form but how to customize the workflow that Azure provides?
Currently the Sign-up form looks like this:
Which is really unlogical. The text boxes under 'Verificatiecode verzenden' (Send verification code) are only useful after the code has received and filled in.
How to customize this part to create a better working workflow:
Add email address -> Send code -> Fill in code and verify --> Fill in additional user details.
Edit:
As recommended by Brad I dived into Identity Experience Framework. An 'intimidating' framework is a big understatement ;(
I watched these videos: https://www.youtube.com/playlist?list=PL4svy-vB4AaxRunWQkxOe8h3zP9jAzS5Z and followed the steps mentioned here:
https://github.com/azure-ad-b2c/azureadb2ccommunity.io/wiki/LocalAndSocialAccount-Sign-In-and-Sign-Up-policy
https://github.com/azure-ad-b2c/samples/tree/master/policies/split-email-verification-and-signup
I'm just at the point that I only want to mimic what I currently have using the 'normal' user flows:
Log-in using Email
Log-in using Facebook
Log-in using Google
The login screen looks the same, I have the email and password buttons and the Facebook and Google buttons, but when I log in with Google I get an error about grant-type not set.
And this is all without trying the split.xml.
I'm so lost in understanding AAD B2C. It should make live easier for developers but I find it very complicated, hard to modify and hard to get the profile data I need and to keep the data in sync.
In order to achieve this with User Flows, you must use the Custom User Interface features, and Javascript to control how and when those fields are displayed.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/javascript-and-page-layout?pivots=b2c-user-flow#enable-javascript
Optionally, you can conduct a similar flow using the Identity Experience Framework (Custom Policies) with either Javascript or where you use two different Self Asserted profiles to move from screen to screen.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-trust-frameworks
Taking the leap from User Flows to the Identity Experience Framework can be intimidating, but would give you the most control in your user experience.
I am working on a project which needs User Authentication. The "Clients" are iOS (Swift) or Android (Kotlin) native applications. The original form of the API (NodeJS) used Facebook and Account Kit for OAuth and Phone authentication respectively. Since Account Kit shutdown, we moved to Firebase Phone Authentication for Phone but left Facebook in its original form. Now, we're wanting to consolidate our Authentication providers (to Firebase) but I can't seem to find a way to "convert" or "import" Facebook users to Firebase-based Facebook users.
So far, I've read through the Documentation, including the category about importing users, but it doesn't seem to indicate an ability to maintain backwards compatibility, while also moving forward to Firebase. What I mean is, it has an ability to set information, but it doesn't indicate that the same information will be used to authenticate that user as the same unique visitor.
What I am looking for is either transitory logic, which will handle this during login, or preferably, a "bulk-insert" type migration. Essentially, I want to have it setup so that the API only needs to keep a single authentication UID, and use only a single third party (even if they then use another subsequent third party) while maintaining user uniqueness (so that it doesn't create a new user for the same Facebook account).
Part of my problem in creating a temporary patch (not necessary if the main question is answered) is that I don't know of a way to differentiate between a Facebook UID and a Firebase UID to fork the logic. Again, this is only relevant if there isn't a solution for migration.
Feel free to request any more details that would be useful.
Update #1
I realized my question was open ended in what I was asking. I've been digging further and can better define my question:
I need a way to bulk insert users into Firebase's Authentication with a provider of Facebook. I know I can import them, via admin.auth().importUsers([...]) and that I can create accounts via admin.auth().createUser({...}) but when I do the former I can't seem to get back the user's UID, and the latter doesn't seem to allow specifying a provider. Am I missing something?
I have a running website, where users already have accounts. And I am trying to create a Google Assistant agent, accessible on Android, to help users access their information.
My issue is that I can't detect returning users on Android Smartphones, each time they have to sign in.
I tried Anonymous User Identity, but it is soon to be deprecated.
Is there an other way to keep track of users?Using some kind of userId that I can store, so I can make "my own Acount Linking" linking the person/Smartphone with already existing user accounts.
There are a few angles to your question.
Is there any way to keep track of users?
Yes... but...
You can store a userId that you generate in the user storage area. You do need to treat this like you would a cookie, so some jurisdictions might impose restrictions on this, but this is one approach to moving from the anonymous ID that is being turned off soon.
But...
How do I let them log into my service through the Action?
That is the problem. The General Policies states the following limitation for collecting user data:
Authentication Data
(including passwords, PINs, and answers to security questions)
Don't collect authentication data via the conversational interface (text or speech).
After a user's account has been linked, PINs or passwords may be used as part of a second verification process.
So you need to use Account Linking to connect to the existing account on your service.
How can I do Account Linking if I don't require Google Sign-In?
You can still use Google Sign-In for Assistant if it will (or may) provide the information as part of the profile that match what you have. So it doesn't need to use the same account - just have the same email (for example).
But that still may not be enough.
For other cases, you can look into setting things up to work with an OAuth server that you control.
So why use Google Sign-In if I setup an OAuth server that uses Google Sign-In?
Google Sign-In is good for a more streamlined flow, if you can use it. It can be done completely with voice, such as with a smart speaker, instead of requiring the user to go to a phone to complete the login. So if you have the user's email address in your account system, and you also get this from Google Sign In, then you can connect the two accounts.
In some cases, such as if the user is expected to have logged into the account on your website first, they won't even need to do that. If both the voice client and web client use the same Google project, then authentication will take place automatically.
I am attempting to our company's Jenkins from the Jenkins user database + matrix based security to using Google Login Plugin and Role based strategy plugin to give us better control of our user accounts.
With this new set up I am wondering how I could go about creating a designated user which is used by scripts which trigger Jenkins jobs remotely. I would like to do this without having to add a user to our company's GSuite account as this costs a few $ per month. Before the switch to Google Login I could just create a user manually in the Jenkins user database and take the API token from there but since switching to Google Login there is no option to add a user (which makes sense given than the users are managed by Google now). At the moment it seems like I have to choose from:
Use the old approach and forget about authenticating through google. This is not a great result as we want to minimize the number of user accounts we have to set up for new people joining the company to overhead of onboarding.
Use Google Login Plugin and create a new dedicated "Jenkins" user in GSuite for these scripting / requirements. This costs money.
Use an existing users API Token to avoid the cost of a new Google User in our GSuite account. This seems like bad practice which I'll regret at some point.
Is there a workaround which doesn't require a designated GSuite user or repurposing an existing Google users credentials just for this purpose?
I did a similar research a while ago and it seems like there is no way to do so right now.
However, I'm using SAML plugin with GSuite instead of Google Login Plugin, but from Jenkins security perspective I assume they work in the same way.
When you're using such plugin, Jenkins creates a securityRealm in its config. In my case it is:
<securityRealm class="org.jenkinsci.plugins.saml.SamlSecurityRealm" plugin="saml#1.0.7">
Therefore, to have SAML and Jenkins security matrix work simultaneously, you have to have several security realms.
Here is a ticket, which describes this issue, but it's still open
Regards!
I was also looking at how to trigger builds remotely when using the Google Login Plugin.
I ended up using the "Build Token Root Plugin" which solved this problem, without any need to create a dedicated user for this.
This plugin offers an alternate URI pattern which is not subject to the usual overall or job read permissions. Just issue an Http GET or POST to buildByToken/build?job=NAME&token=SECRET. This URI is accessible to anonymous users regardless of security setup, so you only need the right token.
https://wiki.jenkins.io/display/JENKINS/Build+Token+Root+Plugin
I'm starting on a project to allow an existing web application to use active directory for authentication but leaving authorization within the application. I want to start off simple so I was thinking a user would type their AD username/password into my existing login form, I would then do an ldap bind against the AD server to authenticate the user.
Once the user is authenticated, I would pull that user from my database which has all the authorization information as to what functions the user can see.
My question is what is the best AD element to store in my table to make the association? In the past I've used username but after looking at some of the elements that AD returns I was wondering if I should use the security ID or GUID or something else?
I've been burned when a username changes like an employee gets married or divorced... so I know that is brittle.
I was targeting windows 2003 AD and above if that makes a difference; this is for a product where some clients have large AD forest and some are small networks.
Storing the SID is the most reliable approach; this is the unique ID that all Microsoft AD things use, security groups, permissions, etc.
If you're building on .Net you should seriously consider .Net 3.5, there's a new namespace System.DirectoryServices.AccountManagement that greatly simplifies code here and gives you nice neat objects to go against.
Unless users share computers, why not use Windows integrated logon? Much easier on the users, easier on yourself as developer, and more secure (one less place a password can be sniffed).
Need I mention that allowing user identities to change is poor corporate security policy? Makes traceability harder, permits some novel attack vectors, and gives you this headache.
As Nick mentions, the SID is a stable identifier, but not something you should ask a user to enter for him/herself!