Rest API call in custom policy in Azure AD B2C - azure

I am new and have tried to build custom policy for sign-in by invoking a REST API call to legacy.
The API expects below parameters as input:
client_id=fixed value, client_secret=fixed value, grant_type=fixed value, scope=fixed value, username=variable, password=variable
The above parameters are not for Azure valued but some fixed values that need to be sent in the request.
I have added few portions in the extensions custom policy but seems the request body is not forming correctly and I am getting the error The claims exchange User Migration Via Legacy specified in step '1' returned HTTP error response with Code Bad Request and Reason 'Bad Request'.
What am I doing wrong here? Please help.
Added my portion :
<BuildingBlocks>
<ClaimsSchema>
<ClaimType Id="RequestBody">
<DisplayName>Request body</DisplayName>
<DataType>string</DataType>
<UserHelpText>RequestBody</UserHelpText>
</ClaimType>
</ClaimsSchema>
<ClaimsTransformations>
<ClaimsTransformation Id="GenerateRequestBody" TransformationMethod="GenerateJson">
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" TransformationClaimType="username" />
<InputClaim ClaimTypeReferenceId="password" TransformationClaimType="password" />
</InputClaims>
<InputParameters>
<InputParameter Id="client_id" DataType="string" Value="client" />
<InputParameter Id="client_secret" DataType="string" Value="sec" />
<InputParameter Id="grant_type" DataType="string" Value="grant" />
<InputParameter Id="scope" DataType="string" Value="scope" />
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="RequestBody" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
</ClaimsTransformations>
<ClaimsProviders>
<ClaimsProvider>
<DisplayName>REST API to communicate with Legacy IdP</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="UserMigrationViaLegacyIdp">
<DisplayName>REST API call to communicate with Legacy IdP</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="AuthenticationType">None</Item>
<Item Key="SendClaimsIn">Body</Item>
<Item Key="AllowInsecureAuthInProduction">true</Item>
<Item Key="ClaimUsedForRequestPayload">RequestBody</Item>
</Metadata>
<InputClaimsTransformations>
<InputClaimsTransformation ReferenceId="GenerateRequestBody" />
</InputClaimsTransformations>
<InputClaims>
<InputClaim ClaimTypeReferenceId="RequestBody" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="tokenSuccess" DefaultValue="false" />
<OutputClaim ClaimTypeReferenceId="migrationRequired" />
</OutputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>

Can you share the actual JSON created by the claim transformation? Is it well formatted? You can make troubleshooting easy by displaying the output of <InputClaimsTransformation ReferenceId="GenerateRequestBody" /> before you actually use it as input claim inside the REST API technical profile. This will reveal what's going on with your JSON format.
To do that, first create a self asserted technical profile and add <InputClaimsTransformation ReferenceId="GenerateRequestBody" /> as an output claim transformation to it. Your output claim should be the claim which you will use later in next step in the journey.
In the user journey, add a step that calls the self asserted technical profile. Add next step with App Insights to write the output claim to App Insights( https://learn.microsoft.com/en-us/azure/active-directory-b2c/analytics-with-application-insights)
This will document claim value that REST API is receiving.

Related

Azure B2C Custom Policy getting 500 Internal Server Error when trying to return alternativeSecurityIds in OutputClaims

I have a User Journey that is taking a user's email address and trying to check if the user is a federated user (as a means to obfuscate the list of all Identity Providers and directly sign a user in with the desired provider). We are calling AAD-UserReadUsingEmailAddress from a custom ValidationTechnicalProfile, and returning alternativeSecurityIds in the OutputClaims. However, when clicking "Continue", there is a 500 Internal Server Error occurring to which Application Insights and B2C Audit Logs are providing no additional information. As soon as alternativeSecurityIds, the ValidationTechnicalProfile will properly execute.
Additionally, clicking the continue button causes a 500 Internal Server Error, the ValidationTechnicalProfile still seems to execute and return some of the claims, although not the alternativeSecurityIds. Those are however included in a JWT token that is returned. Screenshots of the claims from App Insights (using the B2C plugin for VS Code) and the JWT, as well as the 500 error are included.
Per the Microsoft Documentation, alternativeSecurityIds is a valid output claim.
I have seen other posts which suggest using userIdentities (a userIdentityCollection), but this does not appear to be supported by B2C, and in fact, when trying to Persist the claim, causes a 400 error with the following message: "The provided user property value is invalid. Error returned was 400/Request_BadRequest: A value without a type name was found and no expected type is available."
Is there something missing (setup, authorization) that is required in order to properly retrieve the alternativeSecurityIds?
Below are code snippets:
<ClaimsSchema>
<ClaimType Id="alternativeSecurityIds">
<DataType>alternativeSecurityIdCollection</DataType>
<UserInputType>Readonly</UserInputType>
</ClaimType>
<ClaimType Id="identityProviders">
<DataType>stringCollection</DataType>
</ClaimType>
</ClaimsSchema>
<ContentDefinition Id="api.ssosignin">
<LoadUri>{Settings:AzureADB2CTemplateBaseUrl}sso.html</LoadUri>
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:contract:selfasserted:2.1.7</DataUri>
<Metadata>
<Item Key="DisplayName">SSO Sign In</Item>
</Metadata>
<LocalizedResourcesReferences MergeBehavior="Prepend">
<LocalizedResourcesReference Language="en" LocalizedResourcesReferenceId="api.ssosignin.en" />
</LocalizedResourcesReferences>
</ContentDefinition>
<TechnicalProfile Id="SelfAsserted-SsoEmailLookup">
<DisplayName>Lookup email address for SSO user</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.ssosignin</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenContainer" />
</CryptographicKeys>
<IncludeInSso>false</IncludeInSso>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" />
</InputClaims>
<DisplayClaims>
<DisplayClaim ClaimTypeReferenceId="email" Required="true" />
</DisplayClaims>
<OutputClaims>
<!-- Required claims -->
<OutputClaim ClaimTypeReferenceId="objectId" />
<!-- Optional claims -->
<OutputClaim ClaimTypeReferenceId="userPrincipalName" />
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="alternativeSecurityIds" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="AAD-UserReadUsingEmailAddress-SsoUser" ContinueOnError="false" />
</ValidationTechnicalProfiles>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
<TechnicalProfile Id="AAD-UserReadUsingEmailAddress-SsoUser">
<Metadata>
<Item Key="Operation">Read</Item>
<Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
<Item Key="UserMessageIfClaimsPrincipalDoesNotExist">An SSO account with that email was not found.</Item>
</Metadata>
<OutputClaims>
<!-- Required claims -->
<OutputClaim ClaimTypeReferenceId="alternativeSecurityIds" />
</OutputClaims>
<IncludeTechnicalProfile ReferenceId="AAD-UserReadUsingEmailAddress" />
</TechnicalProfile>

Azure AD B2C - Forgot Password User Journey - Don't Allow old password?

I'm building an Azure AD B2C configuration based on custom policies. Sign in, profile edit, password change, etc. are already working as wanted.
But currently I'm struggling with the password forgot policy. I want to achieve that the new password does not equal to old one. Google and the Microsoft docs always give me examples for password changes. When I change the password, I have to enter the old one and the new one. Then I'm able to compare the old and the new one. For example like the way discribed here
But when a user has forgotten his password, then he is - of course - not able to enter the old password to compare it with the new one.
Is there any way to build a real password forgot policy without entering the old password but nevertheless ensure that the new password does not equal the old password?
Thanks in advance!
Alex
I was having the same problem and the answer from Jas Suri helped me a lot. However, I had some problems getting it to work. So, that's why I am sharing my final solution in case someone else is facing the same problem.
I have used the following as a base: https://github.com/azure-ad-b2c/samples/tree/master/policies/password-reset-not-last-password/policy but made some adjustments. Here is what I had to add to my existing policy to make it work:
ClaimSchema:
These claims will be used later.
<ClaimsSchema>
<ClaimType Id="SamePassword">
<DisplayName>samePassword</DisplayName>
<DataType>boolean</DataType>
<UserHelpText />
</ClaimType>
<ClaimType Id="resetPasswordObjectId">
<DisplayName>User's Object ID</DisplayName>
<DataType>string</DataType>
<DefaultPartnerClaimTypes>
<Protocol Name="OAuth2" PartnerClaimType="oid" />
<Protocol Name="OpenIdConnect" PartnerClaimType="oid" />
<Protocol Name="SAML2" PartnerClaimType="http://schemas.microsoft.com/identity/claims/objectidentifier" />
</DefaultPartnerClaimTypes>
<UserHelpText>Object identifier (ID) of the user object in Azure AD.</UserHelpText>
</ClaimType>
</ClaimsSchema>
ClaimsTransformation:
The first claim transformation checks whether resetPasswordObjectId is set, if not the previous attempted login with the new password apparently didn't work and thus the newPassword is not the same as the old / current password. The second claim transformation checks whether the claim SamePassword is equal to false. If not it throws an error and 'You can't use an old password' is displayed. More information on this later.
<ClaimsTransformations>
<ClaimsTransformation Id="CheckPasswordEquivalence" TransformationMethod="DoesClaimExist">
<InputClaims>
<InputClaim ClaimTypeReferenceId="resetPasswordObjectId" TransformationClaimType="inputClaim" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="SamePassword" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
<ClaimsTransformation Id="AssertSamePasswordIsFalse" TransformationMethod="AssertBooleanClaimIsEqualToValue">
<InputClaims>
<InputClaim ClaimTypeReferenceId="SamePassword" TransformationClaimType="inputClaim" />
</InputClaims>
<InputParameters>
<InputParameter Id="valueToCompareTo" DataType="boolean" Value="false" />
</InputParameters>
</ClaimsTransformation>
</ClaimsTransformations>
ClaimsProvider:
The overall idea is to use the newly entered password and attempt to login the user. In case the login is successful, the newPassword is the same as the old / current password and is not allowed. When logging in, we create an output claim and call it resetPasswordObjectId which is either unset or equal to the object id of the logged in user. We then check whether the resetPasswordObjectId exists (done in the claims transformation part), if not the newPassword can be used as it is not the same as the old / current password.
To display the correct error message in case the user entered the old password, we need to override UserMessageIfClaimsTransformationBooleanValueIsNotEqual in the TrustFrameworkLocalization.xml in the <LocalizedResources Id="api.localaccountpasswordreset.en"> like this <LocalizedString ElementType="ErrorMessage" StringId="UserMessageIfClaimsTransformationBooleanValueIsNotEqual">You must not use your old password.</LocalizedString>.
When using the claim provider below, ensure to replace all parts marked with a TODO.
<ClaimsProviders>
<ClaimsProvider>
<DisplayName>Password Reset without same password</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="login-NonInteractive-PasswordChange">
<DisplayName>Local Account SignIn</DisplayName>
<Protocol Name="OpenIdConnect" />
<Metadata>
<Item Key="UserMessageIfClaimsPrincipalDoesNotExist">We can't seem to find your account</Item>
<Item Key="UserMessageIfInvalidPassword">Your password is incorrect</Item>
<Item Key="UserMessageIfOldPasswordUsed">Looks like you used an old password</Item>
<Item Key="ProviderName">https://sts.windows.net/</Item>
<!-- TODO replace YOUR-TENANT-ID -->
<Item Key="METADATA">https://login.microsoftonline.com/YOUR-TENANT.onmicrosoft.com/.well-known/openid-configuration</Item>
<!-- TODO replace YOUR-TENANT-ID -->
<Item Key="authorization_endpoint">https://login.microsoftonline.com/YOUR-TENANT.onmicrosoft.com/oauth2/token</Item>
<Item Key="response_types">id_token</Item>
<Item Key="response_mode">query</Item>
<Item Key="scope">email openid</Item>
<!-- TODO ensure this line is commented out-->
<!-- <Item Key="grant_type">password</Item> -->
<Item Key="UsePolicyInRedirectUri">false</Item>
<Item Key="HttpBinding">POST</Item>
<!-- TODO -->
<!-- ProxyIdentityExperienceFramework application / client id -->
<Item Key="client_id">YOUR-PROXY-CLIENT-ID</Item>
<!-- Native App -->
<!-- TODO -->
<!-- IdentityExperienceFramework application / client id -->
<Item Key="IdTokenAudience">YOUR-IDENTITY-CLIENT-ID</Item>
<!-- Web Api -->
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="username" Required="true" />
<!-- INFO: replaced oldPassword with newPassword, that way we try logging in with the new password. If the login is successful, we know the newPassword is the same as the old / current password-->
<InputClaim ClaimTypeReferenceId="newPassword" PartnerClaimType="password" Required="true" />
<InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" />
<InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" />
<InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
<!-- TODO -->
<!-- ProxyIdentityExperienceFramework application / client id -->
<InputClaim ClaimTypeReferenceId="client_id" DefaultValue="YOUR-PROXY-CLIENT-ID" />
<!-- TODO -->
<!-- IdentityExperienceFramework application / client id -->
<InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="YOUR-IDENTITY-CLIENT-ID" />
</InputClaims>
<OutputClaims>
<!-- INFO: assign the objectId (oid) to resetPasswordObjectId, since the claim objectId might already be set. In that case there would be no way of knowing whether it was set due to the attempted login with the newPassword-->
<OutputClaim ClaimTypeReferenceId="resetPasswordObjectId" PartnerClaimType="oid" />
<OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" />
<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
<OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
<OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
<OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="upn" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
</OutputClaims>
</TechnicalProfile>
<!--Logic to check new password is not the same as old password
Validates old password before writing new password-->
<TechnicalProfile Id="LocalAccountWritePasswordUsingObjectId">
<DisplayName>Reset password</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ContentDefinitionReferenceId">api.localaccountpasswordreset</Item>
<!-- set in the TrustFrameworkLocalization.xml -->
<!-- <Item Key="UserMessageIfClaimsTransformationBooleanValueIsNotEqual">You must not use your old password.</Item> -->
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
</CryptographicKeys>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
<OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="login-NonInteractive-PasswordChange" ContinueOnError="true" />
<ValidationTechnicalProfile ReferenceId="ComparePasswords" />
<ValidationTechnicalProfile ReferenceId="AAD-UserWritePasswordUsingObjectId">
<Preconditions>
<Precondition Type="ClaimEquals" ExecuteActionsIf="true">
<Value>SamePassword</Value>
<Value>True</Value>
<Action>SkipThisValidationTechnicalProfile</Action>
</Precondition>
</Preconditions>
</ValidationTechnicalProfile>
</ValidationTechnicalProfiles>
</TechnicalProfile>
<!-- Runs claimsTransformations to make sure new and old passwords differ -->
<TechnicalProfile Id="ComparePasswords">
<DisplayName>Compare Email And Verify Email</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="SamePassword" />
</OutputClaims>
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="CheckPasswordEquivalence" />
<OutputClaimsTransformation ReferenceId="AssertSamePasswordIsFalse" />
</OutputClaimsTransformations>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
You can do it with some logic with Validation Technical profiles:
Call login-noninteractive with continueOnError=true
Call a claimTransform to generate a boolean if a claim (like objectId) is null
Use the boolean for the proceeding logic, lets call it pwdIsLastPwd
Call a claimTransform to assert pwdIsLastPwd = false
If it is true, throw an error - "you cannot use this password" using the claimTransform error handler
Continue with the rest of reset password flow
References:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/validation-technical-profile#validationtechnicalprofiles
Call Claim transform from VTP, Boolean ClaimTransform check if claim exists
Assert boolean is true/false
"The UserMessageIfClaimsTransformationBooleanValueIsNotEqual self-asserted technical profile metadata controls the error message that the technical profile presents to the user. "

Can you pass password claims between steps in Azure AD B2C Custom Policies?

Can you pass password claims between steps in Azure AD B2C Custom Policies?
My symptom is that after signing up using a multiple page custom policy, a user cannot sign in until they reset their password.
I am asking this as I spent many hours debugging a problem that it turns out could not be fixed. I found the answer under another question (Azure AD B2C Multi steps custom policy) that was differently worded but had similar symptoms.
I am posting here in the hope it is more easily found and helpful to others. Apologies if you think this is a duplicate.
In short, no. See Azure AD B2C Multi steps custom policy.
A password claim is "scoped" to a given step. This means the orchestration step that collects the password claim from the end user must be the same step that writes it to the User object.
I was looking for the same and have found a way to do multi step sign up. I tried several methods, including a outputclaimstransformation to store the password in another claim, but that did not work out. Because I already needed to do some input validation against an API I found a way to also copy the password to a new claim (plaintextPassword) that is not scoped to one orchestration step. This claim can be used in a later step to create the user account with the password provided by the plaintextPassword claim.
Create a self asserted technical profile that has an inputclaim (the password) and a validation technical profile. In the validation technical profile you can copy the password to a claim of type string with an inputclaimstransformation. Then add the new claim as outputclaim to the validation profile and to the technical profile. See code below for an example:
<ClaimType Id="plaintextPassword">
<DisplayName>password</DisplayName>
<DataType>string</DataType>
<UserInputType>TextBox</UserInputType>
</ClaimType>
<ClaimType Id="password">
<DisplayName>Your password</DisplayName>
<DataType>string</DataType>
<UserHelpText>Your password</UserHelpText>
<UserInputType>Password</UserInputType>
</ClaimType>
<ClaimsTransformation Id="CopyPassword" TransformationMethod="FormatStringClaim">
<InputClaims>
<InputClaim ClaimTypeReferenceId="password" TransformationClaimType="inputClaim" />
</InputClaims>
<InputParameters>
<InputParameter Id="stringFormat" DataType="string" Value="{0}" />
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="plaintextPassword" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
<TechnicalProfile Id="SignUp-PasswordValidation">
<DisplayName>Email signup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ServiceUrl">url</Item>
<Item Key="AuthenticationType">ClientCertificate</Item>
<Item Key="SendClaimsIn">Body</Item>
</Metadata>
<CryptographicKeys>
<Key Id="ClientCertificate" StorageReferenceId="B2C_1A_ClientCertificate" />
</CryptographicKeys>
<InputClaimsTransformations>
<InputClaimsTransformation ReferenceId="CopyPassword" />
</InputClaimsTransformations>
<InputClaims>
<InputClaim ClaimTypeReferenceId="claim_to_validate" PartnerClaimType="claim_to_validate" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="plaintextPassword" />
</OutputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
<TechnicalProfile Id="SignUp">
<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="setting.retryLimit">3</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
</CryptographicKeys>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="email" Required="true" />
<OutputClaim ClaimTypeReferenceId="claim_to_validate" Required="true" />
<OutputClaim ClaimTypeReferenceId="password" Required="true" />
<OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
<OutputClaim ClaimTypeReferenceId="plaintextPassword" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="SignUp-Validation" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
In the technical profile where you create the user in AAD add this line:
<PersistedClaim ClaimTypeReferenceId="plaintextPassword" PartnerClaimType="password"/>
I was able to solve the problem. When we have to add the user information (LocalAccountSignUpWithLogonEmail) I removed the validation that called the technical profile that is written in AAD, I changed it to a validation that calls another technical profile. This will copy our password through a ClaimsTransformation that will save our password in another InputClaim to be visible in any other step of our flow.
<ClaimType Id="plaintextPassword">
<DisplayName>password</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="passwordTransformation">
<DisplayName>requestSocialRestSecondCall</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="TransformationPassword" />
</ValidationTechnicalProfiles>
<ClaimsProvider> <!-- Copy Password-->
<DisplayName>Copy Password</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="TransformationPassword">
<DisplayName>Copy Pass</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<InputClaims>
<InputClaim ClaimTypeReferenceId="passwordTransformation" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="passwordTransformation" />
</OutputClaims>
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="Generate_TranformationPassword" />
</OutputClaimsTransformations>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
<ClaimsTransformation Id="Generate_TranformationPassword" TransformationMethod="CopyClaim">
<InputClaims>
<InputClaim ClaimTypeReferenceId="newPassword" TransformationClaimType="inputClaim" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="plaintextPassword" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
I removed the validation that called the technical profile that is written in AAD and changed it to a validation that calls another technical profile.
This will copy the password through a ClaimsTransformation that will save our password in another InputClaim to be visible in any other step of our flow.
<TechnicalProfile Id="SignUp-PasswordValidation">
<Metadata>
<Item Key="ServiceUrl">url</Item>
<Item Key="AuthenticationType">ClientCertificate</Item>
<Item Key="SendClaimsIn">Body</Item>
</Metadata>
What is the url you used?
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
</CryptographicKeys>
What was you application to create the Secret?

Custom Policy RESTful-Api UserJourney Error

I am developing a RESTful Service, which gets called during the Signup/Signin Process in Azure AD B2C. My Service logs state, that data successfully arrives, and output-claims (customerId) get created.
But I receive the following error message, and the user doesn't get created:
AADB2C90161 A self-asserted send response has failed with reason (Internal Server Error).
Correlation ID 7eac5fd2-cd85-4535-b166-4cc8f0264d07
I have oriented myself towards this example: https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/master/scenarios/aadb2c-ief-rest-api-netfw/
Did anyone experience similar issues and has a hint what could be the problem in my case?
in TrustFrameworkExtension:
<ClaimsProvider>
<DisplayName>KTM REST APIs</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="REST-API-SignUp">
<DisplayName>Generate and return customerID claim</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://<my.service.com>/api/Identity/Signup</Item>
<Item Key="AuthenticationType">None</Item>
<Item Key="SendClaimsIn">Body</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="Email" />
<InputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="FirstName" />
<InputClaim ClaimTypeReferenceId="surname" PartnerClaimType="LastName" />
<InputClaim ClaimTypeReferenceId="testClaim" PartnerClaimType="ObjectId" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="customerId" PartnerClaimType="CustomerId" />
</OutputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="customerId" PartnerClaimType="CustomerId" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="REST-API-SignUp" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
In this case, you have a run-time error. The claim type "customerId" is defined as a string in the policy, but looks like the value coming over the wire (where partnerClaimType is "CustomerId") is a number, so the system is unable to map it. See this line:
<OutputClaim ClaimTypeReferenceId="customerId" PartnerClaimType="CustomerId" />
This is how a Rest API will return a string vs a number (note the absence of quotes in a number):
{
"name": "John",
"age": 24
}
While this message can be improved, you should configure your policy to collect logs using Application Insights. This will allow you to debug similar run-time issues more easily.

Can we set custom headers on RESTful API calls in Azure Active Directory B2C custom policies?

I have successfully created an AAD B2C custom policy which makes a call to my application.
Similar to what can be found here:
Integrate REST API claims exchanges in your Azure AD B2C user journey as validation on user input
and here:
Secure your RESTful services using client certificates
<ClaimsProvider>
<DisplayName>XYZ API</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="XYZ">
<DisplayName>XYZ</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://example.com/api/1.0/Users</Item>
<Item Key="AuthenticationType">ClientCertificate</Item>
<Item Key="SendClaimsIn">Body</Item>
</Metadata>
<CryptographicKeys>
<Key Id="ClientCertificate" StorageReferenceId="B2C_1A_XYZRestClientCertificate" />
</CryptographicKeys>
<InputClaims>
<InputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="givenName" />
<InputClaim ClaimTypeReferenceId="surname" PartnerClaimType="surname" />
<InputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="displayName" />
<InputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId" />
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
<InputClaim ClaimTypeReferenceId="otherMails" PartnerClaimType="otherMails" />
</InputClaims>
<OutputClaims>
</OutputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
Our app likes to use custom HTTP headers to track some information about the caller, such as a transaction id. Is it possible to add HTTP headers similar to claims? Something maybe like:
<InputHeaders>
<InputHeader ClaimTypeReferenceId="objectId" HeaderName="transactionId" />
<InputHeader Value="AzureB2C" HeaderName="callerName" />
</InputHeaders>
Right now, it is not possible to split some claims between various places (e.g. body, headers, query string). I suggest you add a request for this feature at the Azure feedback portal for Azure Active Directory.

Resources