AADSTS700016: Application with identifier 'some_id' was not found in the directory 'some_another_id' - azure-active-directory

I need a federated authentication with custom policy (when user authenticated I need him to appear marked as Federated in b2c users, not Others or something else what I could achieve with single tenant), I had it before with default policy setup in azure as OpenId provider, but did not find how to do FEDERATION Authentication with OpenId in custom policy, so I did it with SAML and below what I've got.
I tried Single tenant and it is not what I need. Also problem is not with signing key, because I've already had this issue and resolved this. I created self signed certificate, uploaded it to AAD application first and to b2c policy keys after.
I think the application which authenticate the federation is not an issue, because I works with default policy.
<TechnicalProfile Id="Office-SAML2">
<DisplayName>Microsoft Office 365</DisplayName>
<Description>Login with your ADFS account</Description>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="WantsSignedRequests">false</Item>
<Item Key="PartnerEntity">https://login.microsoftonline.com/<b2c tenant id>/federationmetadata/2007-06/federationmetadata.xml</Item>
<Item Key="XmlSignatureAlgorithm">Sha256</Item>
</Metadata>
<CryptographicKeys>
<Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlCert"/>
<Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlCert"/>
</CryptographicKeys>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="userPrincipalName" />
<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name"/>
<OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name"/>
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email"/>
<OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name"/>
<OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="https://sts.windows.net/<b2c tenant id>/" AlwaysUseDefaultValue="true" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
</OutputClaims>
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
<OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
<OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
<OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
</OutputClaimsTransformations>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop"/>
</TechnicalProfile>
I have been doing everything through this reference
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-custom-setup-adfs2016-idp

I ran in to this problem because I was using the ID of in the Client secret section instead of using the Application (client) ID.

I have faced this error below are the possibilities:
This error means you have made a mistakes while configuring the Client ID OR tenant ID in your code, First please confirm that both are same as your azure portal application client and tenant.
In my case i had entered wrong client id in my code.
Please check this https://github.com/MicrosoftDocs/azure-docs/issues/24673

The problem here is that the AAD Application Registration has an identifier URI that does not match that being requested in the authentication request. You can fix this by:
Copying the URL in the obscured screenshot
Navigating to Azure AD Blade in the Azure AD Tenant to which you want to federate with 3. Access the Enterprise Applications menu, find the App Registration by ApplicationId(ClientId)
Open the Single Sign-On menu.
Paste the URL from the error into the Identifier (Entity ID) option
You also need the correct Reply URL:
https://contoso.b2clogin.com/te/contoso.onmicrosoft.com/<policyd of Base>/samlp/sso/assertionconsumer
You are much better off using OpenId (which also allows for multi tenant access):
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-aad-custom

For me, the problem was that my application Identifier (Entity ID) from Basic SAML Configuration menu, didn't match with the one declared by the application provider.

Adding to this, for me I had to select the following option from the Authentication options.
Supported Account Types Option

Related

Azure Ad b2c custom policy, iframe: Refused to display 'https://login.microsoftonline.com/' in a frame because it set 'X-Frame-Options' to 'deny'

i have a web application (using ASP MVC), i embed an angular website, this page uses Azure Ad b2c for user authentication.
I get the error: Refused to display 'https://login.microsoftonline.com/' in a frame because it set 'X-Frame-Options' to 'deny'
This is my Signup And Signin Policty:
<UserJourneys>
<UserJourney Id="SignUpOrSignIn">
<OrchestrationSteps>
<!-- get AppRoleAssignment -->
<OrchestrationStep Order="4" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="GetUserAppRoleAssignment" TechnicalProfileReferenceId="GetUserAppRoleAssignment" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="5" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
</OrchestrationSteps>
<ClientDefinition ReferenceId="DefaultWeb" />
</UserJourney>
</UserJourneys>
<RelyingParty>
<DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
<UserJourneyBehaviors>
<JourneyFraming Enabled="true" Sources="https://.io https://testsquid.dynatex.io" />
</UserJourneyBehaviors>
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
....
<OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
this is my Multi tenant AD config in B2C_1A_TRUSTFRAMEWORKEXTENSIONS.xml
<ClaimsProvider>
<Domain>microsoftonline.com</Domain>
<DisplayName>Common AAD</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="AADCommon-OpenIdConnect">
<DisplayName>Multi-Tenant Azure Ad</DisplayName>
<Protocol Name="OpenIdConnect" />
<Metadata>
<Item Key="ProviderName">https://login.microsoftonline.com</Item>
<Item Key="METADATA">https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration</Item>
<!-- Update the Client ID below to the Application ID -->
<Item Key="response_types">code</Item>
<Item Key="response_mode">form_post</Item>
<Item Key="scope">openid profile email</Item>
<Item Key="HttpBinding">POST</Item>
<Item Key="UsePolicyInRedirectUri">false</Item>
<Item Key="DiscoverMetadataByTokenIssuer">true</Item>
<Item Key="client_id">....23-34e2ae21b7eb</Item>
<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com</Item>
<!-- <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000,https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item> -->
</Metadata>```
• The below error that you are encountering while using Azure AD B2C user authentication is not because of a misconfiguration in Azure AD B2C custom policy. It is because of an issue in the web browsers’ cookie management policies and settings configured. Because, since Azure AD and Azure AD B2C both rely on cookie-based session authentication mechanism, the authentication information is stored in the browser memory in the form of cookies and only allowed or authenticated information from valid sources is allowed to be shown on the page through them.
Thus, I would suggest you to please ensure that the browser versions are up-to date and the setting ‘Block third party cookies’ is disabled. You will have to go to ‘Settings --> Privacy and Security --> Site settings --> Cookies and site data --> Set ‘Block third party cookies to OFF’'
• Doing the above should help you to resolve the issue, also ensure that you are disabling the ‘Flash and Ads blocker extensions’ too which are messing up with the AAD authentication.
Hence, doing the above should help you to resolve the issue. Please refer the below links for more details on the above: -
https://blog.atwork.at/medium.aspx?id=c14c3ae3-3aba-429d-a748-b74283dbd463&date=/post/2020/09/13
https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/84

Azure B2C - Renaming an output claim

I am using Azure B2C (Azure AD as my identity provider). I am using custom policies, I have a simple goal I am trying to accomplish, I am trying to rename a claim. Here is my example, this is taken from the Azure B2C starter packs https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/master/LocalAccounts
I am requesting my surname from Azure B2C, it returns in a claim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", my goal is to change the name of this claim from "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" to "lastname", I noticed the following definition exists in TrustFrameworkBase.xml:
<ClaimType Id="surname">
<DisplayName>Surname</DisplayName>
<DataType>string</DataType>
<DefaultPartnerClaimTypes>
<Protocol Name="OAuth2" PartnerClaimType="family_name" />
<Protocol Name="OpenIdConnect" PartnerClaimType="family_name" />
<Protocol Name="SAML2" PartnerClaimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" />
</DefaultPartnerClaimTypes>
</ClaimType>
I am just not sure how to get it to return another name, since that is PartnerClaimType and that needs to be exact.
You can rename in relying party technical profile in one of the leaf policies. Use PartenrClaimtype attribute in output claim element.
Define a claim named as last name
<ClaimType Id="lastname">
<DisplayName>LastName</DisplayName>
<DataType>string</DataType>
</ClaimType>
And then in the relying party section
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="lastname" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>

Identity Experience Framework - getting the email claim with a multi-tenant Azure AD custom policy

I've followed the instructions here to set up the Azure AD multi-tenant custom policy in the Identity Experience Framework:
https://learn.microsoft.com/en-gb/azure/active-directory-b2c/active-directory-b2c-setup-commonaad-custom?tabs=applications
However I'm unable to get a claim back containing the email address (corresponding to the "user name" from the external active directory).
The main single-tenant active directory setup works fine, when I use this claim mapping (and the other "social" provider accounts work with PartnerClaimType="email"):
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="upn" />
However I've tried the following combinations for the multi-tenant, and I don't seem to be getting the data back from the provider:
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="upn" />
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="mail" />
Please can someone let me know the correct claim mapping for this, to get the email output from the user flow?
What you are looking for is "preferred_username".
Add <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="preferred_username" /> into TrustFrameworkExtensions.xml file to see if it works.

Azure AD B2C Sign-in Custom Policy remember user

We have a Sign-in Custom Policy setup in Azure AD B2C that customers use to log in our application.
In the Standard B2C policies, users are rememberd and a menu is provided with the list of email addresses that have logged in from a particular machine (and the option to forget them), as in the following screenshot:
List of Users
Our Custom Sign-in Policy works but users have to re-enter their email address every time from their machines. How can we achieve the same behaviour with a Custom Policy?
Here is the technical profile:
<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="setting.showSignupLink">False</Item>
<Item Key="setting.showContinueButton">True</Item>
<Item Key="setting.showCancelButton">True</Item>
<Item Key="EnforceEmailVerification">False</Item>
<Item Key="ContentDefinitionReferenceId">api.selfasserted</Item>
</Metadata>
<IncludeInSso>false</IncludeInSso>
<InputClaims>
<InputClaim ClaimTypeReferenceId="signInName" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="signInName" Required="true" />
<OutputClaim ClaimTypeReferenceId="password" Required="true" />
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="login-NonInteractive" />
</ValidationTechnicalProfiles>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>
EDIT:
Having played around with the new "User Flows" which are currently in the Preview phase in Azure AD B2C, it seems that there are two different versions of the Sign in user journey that are offered:
Sign in: which does not allow for UI customisation (aside from the "Company Branding" feature) and is consistent with the behaviour that I report in the screenshot above.
Sign in v2: Which allows for UI customisation with custom cshtml pages and is consistent with the behaviour I observe when using custom policies. This type of Sign in user flow is not visible or accessible from the existing built-in policies at the moment.
So it seems that the Sign in v2 is the version that is used within custom policies for the sign in user journeys, as it is the version that allows for UI customisation.
SignInV1 vs SignInV2
Built-in policies have been rebranded as User flows. The new ui of Azure Ad B2C is moving into GA. It has some v2 user flows which are in preview currently and will be moved to GA in due course of time.
There is a difference in the way SignInv1 and SignInv2 user flows work. SignIn v1 'interactively' federates with default sign-in experience of Azure Active Directory (AAD), which has "Keep me sign in" (KMSI) feature. SignInV2 has additinal feature of UX customizability. To provide that B2C 'non-interactively' federates with AAD.
As a result of this customizability, there is currently a feature gap between signinv1 and v2
- KMSI
- Forced password reset.
There are plans to work on these features.
Custom policies
This page will tell how to enable KMSI for custom policies.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-kmsi-custom

How to direct B2C Federated user to Microsoft common login endpoint

I am using Azure AD B2C and have added sign in/sign up with custom templates and policies. I am using msal.js on the frontend.
When any user tries to login to our application, we have process to know if the domain is already federated with Microsoft B2C. Once we identify the user, we want to direct the user to Microsoft common login endpoint by passing the login_hint, so that they are forced to use work account and get the id_token.
I am trying to get the endpoint working (need to pass login_hint, don't know how)
directauthority ="https://login.microsoftonline.com/common/oauth2/authorize?"+ this.Config.signUpSignInPolicy;
clientApplication = new Msal.UserAgentApplication(
this.tenantConfig.clientID, this.directauthority,
);
I got an error "endpoints_resolution_error:Endpoints cannot be resolved"
How can I resolve this?
Please suggest
Thanks,
You can add the "domain_hint" and "login_hint" parameters to the Azure AD B2C request:
https://login.microsoftonline.com/<tenant>/oauth2/v2.0/authorize?p=<policy>&...&domain_hint=onmicrosoft.com&login_hint=me#contoso.com
If you set the "domain_hint" parameter to the Azure AD technical profile's <Domain /> value, then Azure AD B2C will redirect to the Azure AD endpoint without showing the sign-up or sign-in page to the end user.
To pass the "login_hint" parameter through from Azure AD B2C to the Azure AD endpoint:
1) Create a "loginHint" claim type:
<BuildingBlocks>
<ClaimsSchema>
<ClaimType Id="loginHint">
<DisplayName>Login Hint</DisplayName>
<DataType>string</DataType>
</ClaimType>
</ClaimsSchema>
</BuildingBlocks>
2) Add the "loginHint" input claim to the Azure AD technical profile:
<ClaimsProviders>
<ClaimsProvider>
<Domain>onmicrosoft.com</Domain>
<DisplayName>Work Account</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="WorkProfile">
<DisplayName>Work Profile</DisplayName>
<Protocol Name="OpenIdConnect"/>
<OutputTokenFormat>JWT</OutputTokenFormat>
<Metadata>
...
</Metadata>
<CryptographicKeys>
...
</CryptographicKeys>
<InputClaims>
<InputClaim ClaimTypeReferenceId="loginHint" PartnerClaimType="login_hint" DefaultValue="{OIDC:LoginHint}" />
</InputClaims>
<OutputClaims>
...
</OutputClaims>
<OutputClaimsTransformations>
...
</OutputClaimsTransformations>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
</ClaimsProviders>
The "loginHint" input claim references a claims resolver that sets this input claim value to the "login_hint" parameter of the Azure AD B2C request.

Resources