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>
Related
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.
I am trying to call a SMS provider through custom policies . the API provided by SMS provider accepts a JSON payload in the format mentioned below
JSON Payload format
I am trying to call this API by passing the JOSN payload, however when I run this policy the content type in the request header is application/x-www-form-urlencoded but the API only accepts application/json.
Below is the code of the restful technical profile
<TechnicalProfile Id="SendOtp">
<DisplayName>Use SMS api to send the code the the user</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://japi.instaalerts.zone/httpapi/JsonReceiver</Item>
<Item Key="AuthenticationType">None</Item>
<Item Key="SendClaimsIn">Body</Item>
<Item Key="ClaimUsedForRequestPayload">RequestBody</Item>
<!-- <Item Key="DefaultUserMessageIfRequestFailed">Default</Item>
<Item Key="UserMessageIfCircuitOpen">Not Reachable</Item>
<Item Key="UserMessageIfDnsResolutionFailed">DNS Failed</Item>
<Item Key="UserMessageIfRequestTimeout">Timeout</Item> -->
</Metadata>
<InputClaimsTransformations>
<InputClaimsTransformation ReferenceId="FormatOTPmsg" />
<!-- <InputClaimsTransformation ReferenceId="createDestArray" /> -->
<InputClaimsTransformation ReferenceId="RequestBody" />
</InputClaimsTransformations>
<InputClaims>
<InputClaim ClaimTypeReferenceId="RequestBody"/>
</InputClaims>
</TechnicalProfile>
Question is how to change the content type of the request ?
You cannot control the content type header, it should respect the method used to send the payload. This might be a bug, raise a MS support ticket.
I don't believe there is a way to change values of headers using RestfulProvider Technical profile in B2C Custom policy. The only custom header we can add is for authentication which can be found here B2C Restful Cryptographic keys. It's obviously not applicable here.
I tried calling some test apis which logs headers and B2C is always sending content-type as 'application/json; charset=utf-8' while using the Meta data
<Item Key="SendClaimsIn">Body</Item>
However using Form instead of body produces the header 'content-type': 'application/x-www-form-urlencoded'
<Item Key="SendClaimsIn">Form</Item>
I am not able to reproduce your issue right now. This is my test api call for reference.
<TechnicalProfile Id="TestEchoJson">
<DisplayName>Test Echo</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ServiceUrl">{Settings:TestApiUrl}</Item>
<Item Key="AuthenticationType">None</Item>
<Item Key="SendClaimsIn">Body</Item>
<Item Key="ClaimUsedForRequestPayload">emailRequestBody</Item>
</Metadata>
<InputClaimsTransformations>
<InputClaimsTransformation ReferenceId="GenerateEmailRequestBody" />
</InputClaimsTransformations>
<InputClaims>
<InputClaim ClaimTypeReferenceId="emailRequestBody" />
</InputClaims>
</TechnicalProfile>
You might have to raise support ticket with Microsoft if the issue persists.
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
I'm trying to call a rest api in a technical profile which requires parameters to be passed to it through the header, but I'm unable to do so. I have:
<TechnicalProfile Id="techProfile1">
<DisplayName>Technical Profile 1</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://xxxxxxx.azurewebsites.net/api/controller/action</Item>
<Item Key="AuthenticationType">Basic</Item>
<Item Key="SendClaimsIn">Header</Item>
<Item Key="AllowInsecureAuthInProduction">true</Item>
</Metadata>
<CryptographicKeys>
<Key Id="BasicAuthenticationUsername" StorageReferenceId="xxxxxx" />
<Key Id="BasicAuthenticationPassword" StorageReferenceId="xxxxxx" />
</CryptographicKeys>
<InputClaims>
<InputClaim ClaimTypeReferenceId="claimName1" PartnerClaimType="paramName1" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="output1"/>
</OutputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
Where the value I'm trying to pass in is the ClaimName1 claim, and the parameter name is paramName1. Am I correct in using the InputClaim section for this?
The response back that I get is: AADB2C90075: The claims exchange 'techProfile1' specified in step '3' returned HTTP error response with Code 'InternalServerError' and Reason 'Internal Server Error'.
Am I right in assuming that the parameter is not being passed to the api? When I change the ServiceUrl to: https://xxxxxxx.azurewebsites.net/api/controller/action?paramName1=yyyy (where yyyy is the value held in the claimName1 claim), then it works as expected.
<Item Key="SendClaimsIn">Header</Item>
instead of the above one try the below one
<Item Key="SendClaimsIn">QueryString</Item>
This will add the input claim as query param.
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" />