We are using Azure B2C as our IdP. We have created custom policies for registration, login and credential management. As part of the registration and login we call REST APIs provided by our back office software. The User Journeys are set up to call the REST API just once. We have seen in Application Insights that the REST APIs are occasionally called several times, usually with the correct data and again with just the object ID.
I have googled extensively and asked on the learn.microsft.com site, but I don't see any reason why the REST API is called several times. There is a retry mechanism in B2C that will try the call again after 30 seconds, but we know it is not this being triggered.
I would appreciate any help as this issue is driving the team nuts!
The output of Application Insights is:
Application Insights
Policy: b2c_1a_signin
Correlation Id: 6618ff5f-c65b-4421-8f5d-f0a7fa...
App insights timestamp: 2022-11-24 13:47:56
User journey is completed: No
Orchestration steps: 2, 3
Exceptions
Processing of the HTTP request resulted in an exception.
Please see the HTTP response returned by the 'Response' property of this exception for details.
Cannot process your login right now, please try again later.
Technical profiles
SelfAsserted-LocalAccountSignin-Email_2 (SelfAssertedAttributeProvider)
TFPGQL-SendLoginMutation (RestfulProvider)
TFPGQL-SendLoginMutation (RestfulProvider) <--- CALLED TWICE
Claims
authenticationSource: localAccountAuthentication
gqlLoginJsonBody: {"subjectId":"b456720d-b9e9-...."}
ipAddress: 185.xxx.xxx.177
objectId: b456720d-b9e9-4ec0-9e9...
objectIdFromSession: True
signInName: trdt2411005#mailinator.com
The technical profile we are using is
<ClaimsTransformation Id="GenerateLoginBody" TransformationMethod="GenerateJson">
<InputClaims>
<InputClaim ClaimTypeReferenceId="objectId" TransformationClaimType="subjectId" />
<InputClaim ClaimTypeReferenceId="blackBox" TransformationClaimType="blackBox" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="gqlLoginJsonBody" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
<TechnicalProfile Id="TFPGQL-SendLoginMutation">
<DisplayName>Send register request to GQL</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://tpappgw.thepools.com/qa_graphql/rest/login</Item>
<Item Key="AuthenticationType">ClientCertificate</Item>
<Item Key="SendClaimsIn">Body</Item>
<Item Key="ClaimUsedForRequestPayload">gqlLoginJsonBody</Item>
<Item Key="DefaultUserMessageIfRequestFailed">Cannot process your login right now.</Item>
<Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
<Item Key="DebugMode">true</Item>
</Metadata>
<CryptographicKeys>
<Key Id="ClientCertificate" StorageReferenceId="B2C_1A_RestApiClientCertificate" />
</CryptographicKeys>
<InputClaimsTransformations>
<InputClaimsTransformation ReferenceId="GenerateLoginBody" />
</InputClaimsTransformations>
<InputClaims>
<InputClaim ClaimTypeReferenceId="ipAddress" DefaultValue="{Context:IPAddress}" AlwaysUseDefaultValue="true" />
<InputClaim ClaimTypeReferenceId="gqlLoginJsonBody" />
</InputClaims>
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="ipAddress"/>
<PersistedClaim ClaimTypeReferenceId="blackBox" />
<PersistedClaim ClaimTypeReferenceId="subjectId" />
<PersistedClaim ClaimTypeReferenceId="loginSuccess" />
<PersistedClaim ClaimTypeReferenceId="userBlocked" />
<PersistedClaim ClaimTypeReferenceId="ioResult" />
<PersistedClaim ClaimTypeReferenceId="loginErrorMessage" />
<PersistedClaim ClaimTypeReferenceId="fsError" />
<PersistedClaim ClaimTypeReferenceId="migrationResponse" />
</PersistedClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="loginSuccess" />
<OutputClaim ClaimTypeReferenceId="userBlocked" />
<OutputClaim ClaimTypeReferenceId="ioResult" />
<OutputClaim ClaimTypeReferenceId="loginErrorMessage" PartnerClaimType="error.message" />
<OutputClaim ClaimTypeReferenceId="fsError" PartnerClaimType="error.fsError" />
<OutputClaim ClaimTypeReferenceId="migrationResponse" />
<OutputClaim ClaimTypeReferenceId="subjectId" />
<OutputClaim ClaimTypeReferenceId="fsId" />
</OutputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
We have investigated the problem and cannot find a reason for the repeat call
Related
I've deployed started pack b2c custom policies using automated tool. Registered SAML application by following MS guidelines.
I can see B2C login screen with sign-in and Sign-up buttons. However, when I click sign up, getting an strange error "The page cannot be displayed because an internal server error has occurred." - Please note sign-in function works fine, wondering why sign-up not working its same user journey for both sign-in and sign-up ( - unified?local=signup&csrf_token URL param returns this error.)
Not sure, what settings could possibly gone wrong here? I've successful use cases for other tenant and followed the same exact approach. I greatly appreciate if you can shed some light on this pls. Pls refer the screen-shot below.
<TechnicalProfiles>
<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>
<Item Key="IpAddressClaimReferenceId">IpAddress</Item>
<Item Key="ContentDefinitionReferenceId">api.localaccountsignup</Item>
<Item Key="language.button_continue">Create</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
</CryptographicKeys>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true" />
<OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
<OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
<OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" />
<OutputClaim ClaimTypeReferenceId="newUser" />
<!-- Optional claims, to be collected from the user -->
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surName" />
<OutputClaim ClaimTypeReferenceId="otherMails" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
</ValidationTechnicalProfiles>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>
I have created a REST API for Azure B2C to return a claim or an error during the account creation flow.
In my Custom Policy I have hooked up the API and it gets called.
However if the API returns either a 400 or 409, the account is still created but the user is presented with the error message on the create page. The user's account is still created despite the error.
The user then fixes the error and clicks create again but can't create the account because it was already created.
I have followed the instructions here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-rest-api-claims-validation
My Claims Provider looks like this and claim from the REST API is called VerifiedDateOfBirth:
<ClaimsProvider>
<DisplayName>REST API</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="REST-Validation">
<DisplayName>Check date of birth</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<!-- Set the ServiceUrl with your own REST API endpoint -->
<Item Key="ServiceUrl">{REST URL}}</Item>
<Item Key="SendClaimsIn">Body</Item>
<!-- Set AuthenticationType to Basic or ClientCertificate in production environments -->
<Item Key="AuthenticationType">None</Item>
<!-- REMOVE the following line in production environments -->
<Item Key="AllowInsecureAuthInProduction">true</Item>
</Metadata>
<InputClaims>
<!-- Claims sent to your REST API -->
<InputClaim ClaimTypeReferenceId="dateOfBirth" />
</InputClaims>
<OutputClaims>
<!-- Claims parsed from your REST API -->
<OutputClaim ClaimTypeReferenceId="VerifiedDateOfBirth" />
</OutputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
And the 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>
<Item Key="IpAddressClaimReferenceId">IpAddress</Item>
<Item Key="ContentDefinitionReferenceId">api.localaccountsignup</Item>
<Item Key="language.button_continue">Create</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
</CryptographicKeys>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true" />
<OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
<OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
<OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" />
<OutputClaim ClaimTypeReferenceId="newUser" />
<!-- Optional claims, to be collected from the user -->
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surName" />
<OutputClaim ClaimTypeReferenceId="dateOfBirth" Required="true" />
<OutputClaim ClaimTypeReferenceId="VerifiedDateOfBirth" Required="true" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
<ValidationTechnicalProfile ReferenceId="REST-Validation" />
</ValidationTechnicalProfiles>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>
When the error occurs I see the following error on the create page:
Do I need to add some additional configuration?
The order of your validation profiles matter in your LocalAccountSignUpWithLogonEmail technical profile. It looks like the first validation that was taking place was the writing of the user account.
Try this instead:
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="REST-Validation" />
<ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
</ValidationTechnicalProfiles>
I have an Azure B2C Custom Flow where I have defined the TrustFrameworkExtension.xml and signupsignin.xml. I have added the technicalProfile listed below with the expectation that a new free form text field will be added to the log in screen where the user can add their customer service rep's name. Unfortunately, this field is not added the login screen, but since I have the default value set to "Joe Representative", every login has an api call that is passing in "Joe Representative". So I have the part about passing the value to my API completed, I just need to know what I need to do to get the free form text to be displayed on the UI. Suggestions?
<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="setting.operatingMode">Email</Item>
<Item Key="ContentDefinitionReferenceId">api.selfasserted</Item>
<Item Key="ServiceUrl">https://somewickedcoolurl</Item>
<Item Key="SendClaimsIn">Body</Item>
<!-- Set AuthenticationType to Basic or ClientCertificate in production environments -->
<Item Key="AuthenticationType">None</Item>
<!-- REMOVE the following line in production environments -->
<Item Key="AllowInsecureAuthInProduction">true</Item>
</Metadata>
<IncludeInSso>false</IncludeInSso>
<InputClaims>
<InputClaim ClaimTypeReferenceId="signInName" />
<!-- Claims sent to your REST API -->
<InputClaim ClaimTypeReferenceId="email" />
<InputClaim ClaimTypeReferenceId="repName" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="signInName" Required="true" />
<OutputClaim ClaimTypeReferenceId="password" Required="true" />
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" />
<!-- Optional claims, to be collected from the user -->
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surName" />
<OutputClaim ClaimTypeReferenceId="repName" DefaultValue="Joe Representative" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="login-NonInteractive" />
</ValidationTechnicalProfiles>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>
You cannot use an orchestration step with Type=CombinedSignInAndSignUp and also modify the Sign In page elements. This step type will always default to username/password regardless of adding output claims to the selfAsserted technical profile that controls the Sign In function.
I have a custom sign-up policy that has 3 validation profiles.
<ValidationTechnicalProfile ReferenceId="UsernameCheck" ContinueOnError = "false"/>
<ValidationTechnicalProfile ReferenceId="API-VerifyStep1" ContinueOnError = "false"/>
<ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonName" ContinueOnError="false" />
<TechnicalProfile Id="UsernameCheck">
<Metadata>
<Item Key="Operation">Read</Item>
<Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
</Metadata>
<IncludeInSso>false</IncludeInSso>
<InputClaims>
<InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="signInNames.emailAddress" Required="true" />
</InputClaims>
<OutputClaims>
<!-- Required claims -->
<OutputClaim ClaimTypeReferenceId="objectId" DefaultValue="NOTFOUND" />
<OutputClaim ClaimTypeReferenceId="objectIdNotFound" DefaultValue="NOTFOUND" AlwaysUseDefaultValue="true" />
</OutputClaims>
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="AssertObjectIdObjectIdNotFoundAreEqual" />
</OutputClaimsTransformations>
<IncludeTechnicalProfile ReferenceId="AAD-Common" />
</TechnicalProfile>
<TechnicalProfile Id="API-VerifyStep1">
<DisplayName>Validate user's input data and return if valid to sign-up</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://...</Item>
<Item Key="SendClaimsIn">Body</Item>
<!-- Set AuthenticationType to Basic or ClientCertificate in production environments -->
<Item Key="AuthenticationType">None</Item>
<!-- REMOVE the following line in production environments -->
<Item Key="AllowInsecureAuthInProduction">true</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="extension_accessNumber" />
<InputClaim ClaimTypeReferenceId="email" />
<InputClaim ClaimTypeReferenceId="signInName" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="extension_error" PartnerClaimType="extension_error" DefaultValue="true" />
<OutputClaim ClaimTypeReferenceId="extension_message" PartnerClaimType="extension_message" DefaultValue="Error"/>
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
<OutputClaim ClaimTypeReferenceId="userPrincipalName" />
</OutputClaims>
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="AssertErrorMessageFalseStep1" />
</OutputClaimsTransformations>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
The problem is all validation profiles are executed regarldess of throwing an error. If either of the first two throw an error I receive a message on the sign-up page. However, the user still gets added to Azure AD. Why does it do this? What is the point of ContinueOnError? How do I ensure the write only happens after the other two are done validating?
Thank you in advance
ContinueOnError is by default false, so you shouldn't need to specify it as long as you want the default behavior.
Since you are using a restful provider, I suspect you are running into the issue mentioned by following thread -
Custom policy REST API ValidationTechnicalProfile ContinueOnError not working for HTTP codes like 404 NotFound and 401 unauthorized
Basically the validation technical profile needs to return 409.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/validation-technical-profile
You can also use Preconditions as mentioned on the above page to avoid executing a technical profile.
It looks like there is not a lot of help and forums on the Azure B2C Custom policy framework.
I have used the following technical profile for my custom policy.
<TechnicalProfile Id="AAD-UserReadUsingEmailAddress">
<Metadata>
<Item Key="Operation">Read</Item>
<Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
<Item Key="UserMessageIfClaimsPrincipalDoesNotExist">An account could not be found for the provided user ID.</Item>
</Metadata>
<IncludeInSso>false</IncludeInSso>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
</InputClaims>
<OutputClaims>
<!-- Required claims -->
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
<OutputClaim ClaimTypeReferenceId="strongAuthenticationPhoneNumber" />
<!-- Optional claims -->
<OutputClaim ClaimTypeReferenceId="userPrincipalName" />
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="accountEnabled" />
<OutputClaim ClaimTypeReferenceId="otherMails" />
<OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
</OutputClaims>
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="AssertAccountEnabledIsTrue" />
</OutputClaimsTransformations>
<IncludeTechnicalProfile ReferenceId="AAD-Common" />
</TechnicalProfile>
This profile looks for the user and comes back with an error message if the user was not found in AD. However I want to show the user a button to sign up after the validation happens. How can I achieve this?
Any help will be appreciated!
Azure AD B2C Custom Policy is now a GA product and it has a lot of good documentation available.
What you want to achieve here very common and has been explained in starter pack. Its called a signuporsignin policy.
Walk through the article
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-get-started-custom
You can also see the policies here
https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/master/SocialAndLocalAccountsWithMfa/TrustFrameworkBase.xml
Look at this technical profile https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/master/SocialAndLocalAccountsWithMfa/TrustFrameworkBase.xml#L981
providing this metadata might help
<Metadata>
<Item Key="SignUpTarget">SignUpWithLogonEmailExchange</Item>
<Item Key="setting.operatingMode">Email</Item>
<Item Key="ContentDefinitionReferenceId">api.selfasserted</Item>
</Metadata>