I am trying to implement MFA phone call support. I have set the meta-data to use "mixed"
<TechnicalProfile Id="PhoneFactor-Verify">
<DisplayName>PhoneFactor</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.PhoneFactorProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ContentDefinitionReferenceId">api.phonefactor</Item>
<Item Key="ManualPhoneNumberEntryAllowed">false</Item>
<Item Key="setting.authenticationMode">mixed</Item>
</Metadata>
but I still see sms option. The technical profile which DisplayControl calls is as follows:
<TechnicalProfile Id="AzureMfa-SendSmsSimple">
<DisplayName>Send Sms</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureMfaProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="Operation">OneWaySMS</Item>
</Metadata>
<InputClaims>
I am guessing, I need to create a new "ValidationClaimsExchangeTechnicalProfile" which will reference a new "TechnicalProfile" with operation for call or something, but I dont see that in any documentation. Can someone pls share a sample or documentation link to create operation for call.
Thanks
Displaycontrol doesn’t support call option. You have to call phonefactor technical profile directly from user journey as per the B2C starter pack.
Related
I am passing an email of a prospective member in the login_hint from my website to B2C. In my custom policy I am setting the email claim of the "SignUp" TechnicalProfile to {OIDC:LoginHint}
<TechnicalProfile Id="CustomLocalAccountSignUpWithLogonEmail">
<DisplayName>Email signup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="IpAddressClaimReferenceId">IpAddress</Item>
<Item Key="ContentDefinitionReferenceId">api.localaccountsignup</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
</CryptographicKeys>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" DefaultValue="{OIDC:LoginHint}" />
</InputClaims>
<OutputClaims>
But instead of seeing the user's email, the string {OIDC:LoginHint} is displayed in the form:
There is a similar question from 2018 with a suggested workaround of using JavaScript to populate the email field on the Sign Up form. But, I don't use custom templates, so the JavaScript workaround won't work for me.
All I need is to populate the email claim with the value passed in {OIDC:LoginHint}. Is there any way to solve this in the policy XML?
Thank you
In a selfAsserted technical profile, you must:
The IncludeClaimResolvingInClaimsHandling metadata must be set to true.
The input or output claims attribute AlwaysUseDefaultValue must be set to true.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/claim-resolver-overview#using-claim-resolvers
An example of using both settings is here
https://learn.microsoft.com/en-us/azure/active-directory-b2c/claim-resolver-overview#restful-technical-profile
We need to see the feasibility of synchronization of user credentials
between the Microsoft AD B2C and proprietary database in real time.
If it is feasible do you have any pointers on 'how to'.
What is the hashing algorithm used in the MS AD B2C credentials? is
there a ay to customize it?
Use a REST API call during the Sign Up and Password Reset authentication journey's to send the captured password claim to your API. Your API can then update your DB to keep it in sync.
You can call your REST API and can send any claims captured in the journey using this guide.
In this case, since you are looking to send a password, you must call your REST API as part of a validation technical profile, instead of directly as an orchestration step.
You can send the plaintext password to your API.
Here is an outline of what you need to configure:
In the sign up technical profile, add a call to your REST API as a validation technical profile.
<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
<DisplayName>Email signup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
...
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
<ValidationTechnicalProfile ReferenceId="REST-SyncPasswordToDB" />
</ValidationTechnicalProfiles>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>
Create the REST API technical profile to send the password to your endpoint:
<TechnicalProfile Id="REST-SyncPasswordToDB">
<DisplayName>REST API call to communicate with Legacy DB</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ServiceUrl">https://myApi.com/api/syncPassword</Item>
<Item Key="AuthenticationType">None</Item>
<Item Key="SendClaimsIn">Body</Item>
<Item Key="AllowInsecureAuthInProduction">True</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
<InputClaim ClaimTypeReferenceId="password" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
For example...
I've tried this in InputClaims
<InputClaim ClaimTypeReferenceId="Step" AlwaysUseDefaultValue="true" DefaultValue="SelfAsserted-Social-Step01" />
And that in OutputClaims
<OutputClaim ClaimTypeReferenceId="Step" />
So capture all in Javascript (Client-side) in page in this way:
var stepPage = $("#Step").text();
switch (stepPage) {
case "OS-SignIn":
do_this();
}
Worked for me purpose, but it looks a workaround...
Finally, my question is: How I achieve this behaviour in a sophisticated way, like a var in javascript created by B2C or something like that? More native...
For this use case, you can use a different content definition id for each technical profile.
And then define a matching content definition with matching id, with the respective HTML dataURI for that specific technical profile.
This way you don't need to determine on the front end what orchestrations step is being rendered, as you'll have a HTML specific for each orchestration step.
See below how i create api.page1 as a content definition for this technical profile. Repeat that pattern for each technical profile. Then each page will reference a unique HTML file.
<ContentDefinition Id="api.page1">
<LoadUri>https://your-storage-account.blob.core.windows.net/your-container/customize-ui-page1.html</LoadUri>
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.0.0</DataUri>
<Metadata>
<Item Key="DisplayName">Signin and Signup</Item>
</Metadata>
</ContentDefinition>
<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
<DisplayName>Local Account Signin</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="SignUpTarget">SignUpWithLogonEmailExchange</Item>
<Item Key="setting.operatingMode">Email</Item>
<Item Key="ContentDefinitionReferenceId">api.page1</Item>
How do I enable email verification in B2C w/ custom policies?
In an attempt to reverse engineer it, I tried disabling it in a built-in policy and downloaded the policy. I tried adding that metadata item to my self-asserted technical profile but that didn't work.
Reverse Engineer Test | Built-In Policy
<TechnicalProfile Id="SelfAsserted-Input">
<Metadata>
<Item Key="EnforceEmailVerification">False</Item>
</Metadata>
</TechnicalProfile>
My Self-Asserted Technical Profile
<TechnicalProfile Id="LocalAccountSignUp">
<DisplayName>User signup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="EnforceEmailVerification">True</Item>
</Metadata>
...
</TechnicalProfile>
I'm using usernames for local accounts incase that matters.
Whether a local account is created with an email address- or user name-based sign-in name, you add email verification by adding PartnerClaimType="Verified.Email" to the "email" output claim of your self-asserted technical profile, as follows:
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true" />
As part of a custom policy, we make a call to a Rest service. We need to send HTTP headers as part of this. Is it possible to send HTTP Headers as part of a RestfulProvider call?
We would at least like to send Accept=application/json to the service.
<TechnicalProfile Id="Restful-ProxyAuthValidation">
<DisplayName>Restful Claims Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
<Metadata>
<Item Key="ServiceUrl">https://contoso.azurewebsites.net/api/GFAuth</Item>
<Item Key="AuthenticationType">None</Item>
<Item Key="SendClaimsIn">Body</Item>
<Item Key="issuer">https://contoso.azurewebsites.net/</Item>
</Metadata>
....
You can send the claims in headers by adding the following metadata item to the (RestfulProvider) technical profile:
<Item Key="SendClaimsIn">Header</Item>
All the InputClaims of the technical profile will be sent in headers.