I'm currently using built-in attributes.
I'd like to get the "age_range" and "gender" from the FB.
Do I need to deal with custom policies as explained in the following topic:
how to get Facebook profile picture using Azure AD B2C
how to get Facebook profile picture using Azure AD B2C
to get them?
Thanks!
Yes, you will have to create a custom policy for that, and then:
1: Declare the "ageRange" and "gender" claim types in the extension file.
2: Add both the "age_range" and "gender" fields to the "ClaimsEndpoint" metadata item and the "ageRange" and "gender" output claims to the "Facebook-OAUTH" technical profile.
3: Issue the "ageRange" and "gender" claims in the relying party file.
If you are wanting to save the "age_range" and "gender" fields from Facebook as attributes to Azure AD B2C, then you must:
1: Follow the Azure Active Directory B2C: Creating and using custom attributes in a custom profile edit policy steps to create the custom attributes for "AgeRange" and "Gender".
2: Change the claim type declarations, as well as all other references to them, from "ageRange" and "gender" to "extension_AgeRange" and "extension_Gender".
3: Add the "extension_AgeRange" and "extension_Gender" claims in the extension file to the "AAD-UserWriteUsingAlternativeSecurityId" and "AAD-UserReadUsingAlternativeSecurityId" technical profile:
<ClaimsProvider>
<DisplayName>Facebook</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="AAD-UserReadUsingAlternativeSecurityId">
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="extension_AgeRange" />
<OutputClaim ClaimTypeReferenceId="extension_Gender" />
</OutputClaims>
</TechnicalProfile>
<TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="extension_AgeRange" />
<PersistedClaim ClaimTypeReferenceId="extension_Gender" />
</PersistedClaims>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
Related
I need help to solve a problem I have, we need to create a custom policy, which we already have created, but we need to read the value of the user's employeeid in Azure AD, so that when you sign in the first time, this is registered in B2C with that value. I put images to understand it:
Azure AD:
but when I sign in, the user in Azure AD B2C doesn't have the employeeid:
I defined in the custom policy the claim:
<ClaimType Id="extension_employeeid">
<DisplayName>EmployeeId</DisplayName>
<DataType>string</DataType>
<DefaultPartnerClaimTypes>
<Protocol Name="OAuth2" PartnerClaimType="employeeid" />
<Protocol Name="OpenIdConnect" PartnerClaimType="employeeid" />
<Protocol Name="SAML2" PartnerClaimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/employeeid" />
</DefaultPartnerClaimTypes>
<UserHelpText>Your EmployeeId. </UserHelpText>
<!--<UserInputType>Readonly</UserInputType>-->
<UserInputType>TextBox</UserInputType>
</ClaimType>
but the value of employeeid that is returned is empty.
How I can fix it?
Please check the User profile attributes in AAD B2C to get extension attributes for builtin attributes and employeeId is identifier attributes.
Use PersistedClaims to write data to the user profile i.e.; Write data during a federated account first-time sign-in flow and OutputClaims to read data from the user profile within the respective Active Directory technical profiles.
In your trustframeworkextensions file
<!-- Write data during a federated account first-time sign-in flow. -->
<TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
<InputClaims>
<InputClaim ClaimTypeReferenceId=" extension_EmployeeId " />
</InputClaims>
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId=" extension_EmployeeId " />
</PersistedClaims>
<OutputClaims>
ClaimTypeReferenceId="extension_EmployeeId" PartnerClaimType="extn.EmployeeId" " Required="true" />
</OutputClaims>
</TechnicalProfile>
Make TechnicalProfile Id =”AAD-UserReadUsingObjectId” to Read data
after user authenticates with a local account.
If SAML is sending a claim "employeeId" than the mapping is
<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="employeeId" />
Or try Technical Profile to output with PartnerClaimType as extension_employeeNumber
Also see Azure AD B2C: Custom claims with custom policies - Microsoft Q&A
Make sure to enable extension attributes in the custom policy,
provide Application ID and Application Object ID in the AAD-Common
technical profile metadata
Azure Active Directory
See: application properties
Please note that the Claim you set in SignUpOrSignin will be only
returned after your sign-up at that time. The custom attribute won't
be stored into Azure AD. Make sure to set the value of extension in
Base policy file .
References:
azure ad b2c - B2C SAML missing claims - Stack Overflow
Reading Extension Claims in Azure AD B2C - Stack Overflow
I'm using Graph to query a user profile in Azure B2C. I'm able to query the users, but I don't see the Source field to determine the Source of Authority. What field is this?
I'm currently using the .28-preview of the Microsoft.Graph.Beta NuGet package.
And this is what I see in the debugger under Identities:
How would I tell the difference if that was a Google account or an Azure AD account?
Using Microsoft Graph, it’s the issuerId field within the Identities array and only returns on beta version.
Source is not included in the identities array, and is also not included in the properties.
As this issue with PowerShell shows, onPremisesSyncEnabled property will help.
I solved this by creating a custom attribute and then in the custom policies setting the custom attribute based on signup method (see alternative solution near the end).
How to define custom attributes and use them with the MS Graph API and custom policies is explained pretty well here. The hardest part is perhaps getting the custom policy right. I did everything in TrustFrameworkExtensions.xml. First defining an "extension_authoritySource" ClaimType:
<ClaimType Id="extension_AuthoritySource">
<DisplayName>AuthoritySource</DisplayName>
<DataType>string</DataType>
</ClaimType>
Then in <TechnicalProfile Id="Facebook-OAUTH"> I added an OutputClaim which sets this custom attribute to facebook, but this will only be persisted if a PersistedClaim is made in UserWriteUsingAlternativeSecurityId as shown below:
<OutputClaim ClaimTypeReferenceId="extension_AuthoritySource" DefaultValue="Facebook"/>
To persist the custom attribute I added the following to ClaimsProviders:
<ClaimsProvider>
<DisplayName>Azure Active Directory</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="AAD-Common">
<Metadata>
<Item Key="ClientId">[b2c-extensions-app application ID]</Item>
<Item Key="ApplicationObjectId">[b2c-extensions-app application ObjectId]</Item>
</Metadata>
</TechnicalProfile>
<!-- Write data during a local account sign-up flow. -->
<TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="extension_AuthoritySource" DefaultValue="local"/>
</PersistedClaims>
</TechnicalProfile>
<TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="extension_AuthoritySource" DefaultValue="social"/>
</PersistedClaims>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
Note that with the above email signups will always be set as "local", while UserWriteUsingAlternativeSecurityId sets it as "social", but is overwritten by the output claim from facebook.
My thinking here is that UserWriteUsingLogonEmail is only ever used by email signup, whereas UserWriteUsingAlternativeSecurityId could potentially be used by several federated logins, although at the moment I only use facebook.
Alternative without Custom Attribute
Alternatively, if you are not using custom policies or cannot use the approach above for another reason, you can use the MS Graph API and look in the "identities" array which contains the sign in type. So for a given user GET: https://graph.microsoft.com/v1.0/users/[Users objectID Guid]?$select=identities
In this array you can find for a local signup:
{
"signInType": "emailAddress",
"issuer": "[yourdomain].onmicrosoft.com",
"issuerAssignedId": "[email]"
}
and for facebook:
{
"signInType": "federated",
"issuer": "facebook.com",
"issuerAssignedId": "[number]"
}
Every user also has a "userPrincipalName" item in the identities array so you will have to have some logic to loop through the array and only look for the signInType which you want to support. Yet another reason for preferring using custom attribute and setting the authority source yourself.
I'm using Azure AD B2C.
I've created a Sign up v2 user flow with multifactor authentication enabled. When I run the user flow and go through the sign up process including MFA via SMS to my specified mobile phone number, I'm returned to the reply URL that I've configured - jwt.ms.
The id token has return claims including my email address as well as other attributes that I've configured to return, but nothing regarding the mobile phone number used for MFA. There doesn't appear to be a way to configure the user flow to include this in the return claims. Does anyone know if this is possible and if so, how to do it?
Cheers.
The phone number is read from and written to the strongAuthenticationPhoneNumber property of the user object.
Currently, this property is not available to a built-in policy (i.e. a user flow), but it is available to a custom policy.
If you use the custom policy starter pack for MFA, then you can add the strongAuthenticationPhoneNumber claim, as an outgoing claim in the ID token, as follows:
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
...
<OutputClaim ClaimTypeReferenceId="strongAuthenticationPhoneNumber" PartnerClaimType="phone_number" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
I'm using custom policies in order o integrate Azure B2C AD. I need to be able to use single sign on to Microsoft Business Accounts. I was able to make it work, nevertheless, it doesn't return the emails clain my tokens.
Here is what I did:
Downloaded the Start Pack “SocialAndLocalAccountsWithMfa”
I made the changes to the related files based in the articles
below(step 3 and 4)
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-commonaad-custom
Return emails on custom policies
Any idea why it is not working? Thank you in advance!
It seems that the "emails" claim is being returned by a custom OutputClaimsTransformation, the configuration of which isn't available in the samples.
You need to get the email claims dynamically created.
Please see this thread which provides a workaround to your situation.
You must map to the email claim that is used by Azure AD B2C from the upn claim that is issued by Azure AD (which, by convention, should map to the email address for the work account) as follows:
<ClaimsProvider>
<Domain>commonaad</Domain>
<DisplayName>Common AAD</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="Common-AAD">
<DisplayName>Multi-Tenant AAD</DisplayName>
<Protocol Name="OpenIdConnect" />
...
<OutputClaims>
...
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="upn" />
</OutputClaims>
...
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
The AAD-UserWriteUsingAlternativeSecurityId technical profile adds this email claim to the otherMails claim by invoking the CreateOtherMailsFromEmail claims transformation and then saves otherMails claim to the user object.
I have set up an Azure B2C tenant and used custom policies to add azure ad as an IDP so that users can sign up with their domain accounts. I can build a custom page where ask them for their email and then redirect them to the proper policy(one for work domain accounts and another for personal emails), so that they do not have to make the choice between work and personal emails. The problem is that I do not want to make the user enter the email once again. Is there a way/option to do this? I basically want to achieve something similar to what the common endpoint of Azure AD does for all accounts.
For a custom policy, if you add the "login_hint" query string parameter to the OpenID Connect authentication request, then you can default the login field to this login hint by adding the "DefaultValue" attribute to the "signInName" input claim for the "SelfAsserted-LocalAccountSignin-Email" technical profile as follows:
<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
<DisplayName>Local Account Signin</DisplayName>
...
<InputClaims>
<InputClaim ClaimTypeReferenceId="signInName" DefaultValue="{OIDC:LoginHint}" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="signInName" Required="true" />
...
</OutputClaims>
...
</TechnicalProfile>
The "DefaultValue" attribute references a claims resolver that sets the "signInName" claim type to the "login_hint" parameter of the OpenID Connect authentication request.
See the Set up direct sign-in using Azure Active Directory B2C article for more information about passing the "login_hint" query string parameter.