We are using Azure B2C for our Identity provider, but it is clear that users are finding the process a bit clunky. Mostly this appears to be because of the synchronous nature of the signup process.
We do want to verify the email address and MFA phone number, but ideally not at the point at which they are entered. Is there a way that we can leverage a graph API call to deal with this, or use a custom policy to achieve the same?
We would also like a clear separation of the signup/signin process. Such that a user can be directed to these pages directly and they can also be branded.
You might be able to implement this with two custom policies:
A sign-up policy that prompts the new customer for the email address and the phone number and creates a new user with these marked as unverified. This custom policy can be invoked at the Account Creation step.
A verification policy that verifies the unverified email address, via the built-in email message, and then the unverified phone number, via the built-in phone call or text message. This custom policy can be invoked at the Application Complete step.
Note that it isn't the sign-up policy that sends the verification code but the verification policy that sends it. I don't know if this is acceptable for the desired experience but the custom policy that sends the verification code must be the same one that validates it.
(There is an alternate flow where after the sign-up policy has completed, your end application sends a custom email message, containing a verification link, which when opened by the end user is validated by your end application and then the verification policy -- minus the email verification step since the email address has already been verified -- is started).
If this proposed solution is interesting to you, then I can attempt to provide the full details of the custom policies based on one of the custom policy starter packs.
Updated on 15 February 2019
I've published the following custom policy samples to this GitHub repository. The second and third policies implement the above flow.
sign_up_sign_in
Sign-up for a local account using an e-mail address and a phone number. The end user is prompted for verification of the e-mail address and the phone number.
Sign-in for a local account using an e-mail address or a phone number. If the e-mail address hasn't been verified, then the end user is prompted for verification of the e-mail address. If the phone number hasn't been verified, then the end user is prompted for verification of the phone number.
sign_up_without_verification
Sign-up for a local account using an e-mail address and a phone number. The end user is not prompted for verification of the e-mail address or the phone number.
sign_in_with_verification
Sign-in for a local account using an e-mail address or a phone number. If the e-mail address hasn't been verified, then the end user is prompted for verification of the e-mail address. If the phone number hasn't been verified, then the end user is prompted for verification of the phone number.
Related
I am building a custom policy for B2C Sign up.
We currently do not use B2C to do sign ups, but im looking to migrate. Part of this process would require the use of an email and a phone number.
The phone number ONLY would need to be verified.
So after the user signs up for an account an SMS or phone call would verify that they own that phone number.
Looking in the documentation, i see verify phone number, but its for sign up with a phone number. I dont want to do that.
I just want the phone number to verify during the sign up process.
Any insight?
You could use the PhoneFactor technical profile.
The "PhoneFactor-InputOrVerify" flow asks for a phone number if not present and verifies or just verifies if present.
Use the default starter pack. Just add a precondition to skip the phonefactor step if newUser claim does not exist. That will trigger MFA prompt only on sign up.
I try to set up the email channel for a bot on the Azure portal using a company email address. The address uses password authentication. When I try to save I receive Unable to save. Unable to validate the given credentials. ID: b8f65400c0bbb04890efdfa2950940d1. Is this supposed to work?
If I use a company test tenant with an email address ending in onmicrosoft.com registration succeeds.
The only difference I see when doing one of the connection tests on https://testconnectivity.microsoft.com/ (Mailbox provisioning test) is that I get a company login page with the company email address and the standard Microsoft prompt with the onmicrosoft account.
There may be another way, but for my organization, we found the same thing and the solution was for us to create an onmicrosoft.com email address to use for the email channel for the bot. It shouldn't actually matter if you only have access to do this in the test tenant; all you're doing is setting up a channel to communicate with the bot, and you can give you bot access to connect to your production tenant if there are functions there you need.
Currently I am capturing the users email and phone when they sign up. Once they are signed up, they log in with their email and password. I would like to change this so they login with their phone and password instead of their email address. What update do I need to make in my custom policies to achieve this?
There is GitHub sample Where you can login users solely on Phone Number and MFA via SMS or Phone Call. This approach is passwordless. Hope this will helps your query
I need some guidelines or documents to make User silent Activation(directly activate the User without sending the email) through API or UI in DocuSign.
Silent Activation using API is deprecated now and DocuSign does not allow any DS Accounts to use this in their DS plan. There are two ways to activate the user without send the email, and both ways need that you should claim emaildomain in DocuSign and all the users should belong to this claimed email domain:
a. Using SSO, you claim your email domain in the DocuSign and configure your Identity provider with DocuSign, and once SSO is correctly configured then you can activate the user without any emails.
b. A new feature added recently, with this feature You need to claim your domain, create an Organization, then there is setting at the domain level (see below snapshot) which you can select to add a user within the claimed email domain without sending an email.
I have a DocuSign integration scenario that has resulted in what look to be multiple DS accounts created using the same email address but different passwords. I can login w\ the same email address, use two different passwords, and end up in two entirely different accounts.
Yes this is by design. The DocuSign platform uniquely identifies accounts based on user email and user name combinations. So creating multiple user accounts under the same email address is allowed.
One other thing to add here, there is also an option in DocuSign called
AnySigner
which allows you to send signature requests to AnySigner recipients which means all you send to is an email address (i.e. no username) and anyone who has access to that email account can sign and complete. This is a popular option for when you need something signed by anyone in a given department. For instance, you need a form signed by someone in your Human Resources department which has a common email they use.