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>
Related
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
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.
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
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
As i understand from documentation, Azure AD B2C creates a new local account for every user that comes from a social login such as GMail/Facebook while signin first time (Correct me, if i'm wrong). However i want to intercept this and link the user to an already existing (user's own) local account without creating a new local account, through custom policies.
The Wingtip sample contains an example of this flow.
See the "B2C_1A_link" relying party file and the "Link" user journey for reference.
Note this user journey prompts the end user to log in with a local account before they log in with the social account.
A detailed sample is given here.
Updating "user identities" will link the social account with the local account.
This can be achieved by having a user journey similar to the below.
<UserJourney Id="AccountLinkage">
<PreserveOriginalAssertion>false</PreserveOriginalAssertion>
<OrchestrationSteps>
<!-- Demo: The following orchestration step is always executed.
Asks user to sign-in with local account (only)-->
<OrchestrationStep Order="1" Type="ClaimsProviderSelection" ContentDefinitionReferenceId="api.idpselections">
<ClaimsProviderSelections>
<ClaimsProviderSelection TargetClaimsExchangeId="LocalAccountSigninEmailExchange" />
</ClaimsProviderSelections>
</OrchestrationStep>
<!-- Demo: Sign-in with local account-->
<OrchestrationStep Order="2" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- Demo: After user is sign-in, it reads the user, by user object ID,
from the Azure AD identity store. An error is raised if the user does not exist. -->
<OrchestrationStep Order="3" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- Demo: After user is sign-in, and we have the user object ID.
Now, ask the user to re-sign-in, but this time with
one of the social account. This orchestration step, displays the sign-in with social
account buttons.
Note, You may want to add additional social accounts here-->
<OrchestrationStep Order="4" Type="ClaimsProviderSelection" ContentDefinitionReferenceId="api.idpselections">
<ClaimsProviderSelections>
**<ClaimsProviderSelection TargetClaimsExchangeId="GoogleExchange" />
<ClaimsProviderSelection TargetClaimsExchangeId="AmazonAccountExchange" />**
</ClaimsProviderSelections>
</OrchestrationStep>
<!-- Demo: Run the sign-in with social account, based on user choice (from previous step)
Note, You may want to add additional social accounts here -->
<OrchestrationStep Order="5" Type="ClaimsExchange">
<ClaimsExchanges>
**<ClaimsExchange Id="GoogleExchange" TechnicalProfileReferenceId="Google-OAUTH" />
<ClaimsExchange Id="AmazonAccountExchange" TechnicalProfileReferenceId="AmazonAccount-OAuth2" />**
</ClaimsExchanges>
</OrchestrationStep>
<!-- Demo: Updates the social account for a user, identified by the object
identifier for the user, in the Azure AD identity store.
An error is raised if the user does not exist. -->
<OrchestrationStep Order="6" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AAD-UserWriteUsingAlternativeSecurityId-ThrowIfNotExists" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId-ThrowIfNotExists" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- Demo: Re-reads the user, by user object Id, from the Azure Active Directory.
An error is raised if the user does not exist. -->
<OrchestrationStep Order="7" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AADUserReadWithObjectIdAfter" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- Demo: Issues a JWT token to the relying party. -->
<OrchestrationStep Order="8" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
</OrchestrationSteps>
</UserJourney>
Then create a 'LinkExternalAccount.xml' policy similar to the below.
<RelyingParty>
<!-- Demo: This relying party policy executes the `AccountLinkage` user journey.
Please see the B2C_1A_Link_TrustFrameworkExtensions policy for more details -->
<DefaultUserJourney ReferenceId="AccountLinkage" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="identityProvider" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
Once we run our 'Linkexternalaccount.xml' it will redirect to our local account login and after successful login, it will ask for IDP selection and based on user selection 'User identities' attribute will be updated. We can check the same by querying against the user. A sample user identity looks like below,
**"userIdentities": [
{
"issuer": "google.com",
"issuerUserId": "MTA5MjA5ODQwNzAyNjc3NTEzMzM5"
}**