We are following https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-password-change#:~:text=Choose%20All%20services%20in%20the,for%20and%20select%20the%20TrustframeworkExtensions. to setup change password via custom policy.
Positive scenario works well, however, if a user provides incorrect old password, we get a message 'The username or password provided in the request are invalid.' Didn't find from where the message is coming.
Any leads would be helpful.
Verify in your validation technical profile in the metadata and confirm whether this is the information. see example below:
<TechnicalProfiles>
<TechnicalProfile Id="login-NonInteractive">
<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>
<Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
<Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
<Item Key="response_types">id_token</Item>
<Item Key="response_mode">query</Item>
<Item Key="scope">email openid</Item>
<Item Key="grant_type">password</Item>
<!-- Policy Engine Clients -->
<Item Key="UsePolicyInRedirectUri">false</Item>
<Item Key="HttpBinding">POST</Item>
</Metadata>
Related
I have following the tutorial
https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-multi-tenant?pivots=b2c-user-flow
I have a button showing up and it looks like it works but when I login with a work account I get
Selected user account does not exist in tenant 'Default Directory' and
cannot access the application '' in that tenant. The account needs to
be added as an external user in the tenant first. Please use a
different account.
It seems to work with a gmail account but not another tenant's account.
My question is how do I get it to work with another tenants account
Here are my 3 custom xml files
https://easyupload.io/m/w0gxlj
I tried to reproduce the same in my environment and got the same error as below:
To resolve the error, please try the below:
I created an Azure AD Application and configured redirect URI:
Now, I created a Policy Key like below:
To configure Azure AD as Identity Provider, I added the ClaimsProvider in the TrustFrameworkExtensions.xml file like below:
<ClaimsProvider>
<Domain>testaadb2c01</Domain>
<DisplayName>Common AAD</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="AADCommon-OpenIdConnect">
<DisplayName>Common AAD</DisplayName>
<Description>Login with your Contoso account</Description>
<Protocol Name="OpenIdConnect"/>
<Metadata>
<Item Key="METADATA">https://login.microsoftonline.com/testaadb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration</Item>
<!-- Update the Client ID below to the Application ID -->
<Item Key="client_id">CLIENTID</Item>
<Item Key="response_types">id_token</Item>
<Item Key="scope">openid profile</Item>
<Item Key="response_mode">form_post</Item>
<Item Key="HttpBinding">POST</Item>
<Item Key="UsePolicyInRedirectUri">false</Item>
<Item Key="DiscoverMetadataByTokenIssuer">true</Item>
<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
</Metadata>
<CryptographicKeys>
<Key Id="client_secret" StorageReferenceId="B2C_1A_AADAppSecret"/>
</CryptographicKeys>
<OutputClaims>
------
</OutputClaims>
<OutputClaimsTransformations>
------
</OutputClaimsTransformations>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin"/>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
<ClaimsProvider>
<DisplayName>Azure Active Directory</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="AAD-Common">
<DisplayName>Azure Active Directory</DisplayName>
<Metadata>
<Item Key="ApplicationObjectId">OBJECTID</Item>
<Item Key="ClientId">CLIENTID</Item>
</Metadata>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
<ClaimsProvider>
<DisplayName>Local Account SignIn</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="login-NonInteractive">
<Metadata>
<Item Key="client_id">CLIENTID</Item>
<Item Key="IdTokenAudience">AUDIENCE</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="client_id" DefaultValue="XXXXXX"/>
<InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="XXXXXX"/>
</InputClaims>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
</ClaimsProviders>
When I run the custom Policy, I got the login screen successfully like below:
When I tried to login with AzureAD User account, I am able to sign-in successfully like below:
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.
When I clicked on change password in our app . you are redirect to the change password custom policy in b2c.ask for login again if user is already sign in via b2c .how to avoid login process and how to remove prompt=login from url?
Please check if below reference can be helpful.
Verify in your validation technical profile in the metadata if prompt key is present and confirm and avoid prompt=login by giving the prompt=none and should be paired with a login_hint to indicate which user must be signed in.
These parameters ensure that the user isn't presented with any
interactive prompt at all.
<TechnicalProfiles>
<TechnicalProfile Id="login-NonInteractive">
<DisplayName>Local Account SignIn</DisplayName>
<Protocol Name="OpenIdConnect" />
<Metadata>
...
...
<Item Key="ProviderName">https://sts.windows.net/</Item>
<Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
<Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
<Item Key="response_types">id_token</Item>
<Item Key="response_mode">query</Item>
<Item Key="scope">email openid</Item>
<Item Key="grant_type">password</Item>
<!-- Policy Engine Clients -->
<Item Key="UsePolicyInRedirectUri">false</Item>
<Item Key="HttpBinding">POST</Item>
References:
Microsoft identity platform and OpenID Connect protocol - Microsoft
identity platform | Microsoft Docs
azure ad b2c - Change Password with Custom Policy - Stack
Overflow
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>
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.