I am looking to capture an email address from a specific internal domain during signup, but I don't want to users to enter the domain portion of the address. However I am trying to figure out the best way to signal the user to NOT enter the domain.
I would like to customize the default login page to include the domain shown after the textbox, something like below.
I know I could write a whole custom UI page to do this, but I was hoping to be able to do this with just a simpler customization of the default UI. Is this possible?
• I would suggest you to please use the ‘login_hint’ and ‘domain_hint’ query parameters in the 2C custom policy regarding the need to show a domain name during the signup user flow. By specifying the ‘login_hint’ parameter in the signup custom policy, Azure AD B2C automatically populates the sign-in name while the user only needs to enter the password for his credentials though the user gets the option to change the sign-in name that is automatically populated from the custom policy to enter the sign-in name of his choice.
Similarly, regarding the domain, the ‘domain_hint’ query parameter provides a hint by auto-populating the domain name for the social IDP for which the sign-in is recommended. These two options mostly satisfy your requirement of not requiring a user to enter the domain name during login. Kindly find the below samples of the above query parameters for your reference: -
Domain hint: -
<ClaimsProvider>
<!-- Add the domain hint value to the claims provider -->
<Domain>facebook.com</Domain>
<DisplayName>Facebook</DisplayName>
<TechnicalProfiles>
...
Login hint: -
<ClaimsProvider>
<DisplayName>Local Account</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
<InputClaims>
<!-- Add the login hint value to the sign-in names claim type -->
<InputClaim ClaimTypeReferenceId="signInName" DefaultValue="{OIDC:LoginHint}" />
</InputClaims>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
For more information on the above, kindly refer the below documentation links: -
https://learn.microsoft.com/en-us/azure/active-directory-b2c/direct-signin?pivots=b2c-custom-policy
Azure B2C with domain hint instead of IdP buttons
Related
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 have Azure B2C with custom policies with Local Login and Microsoft Account login enabled. I have started with the starter pack and made some modifications to add my custom logic for validate and add additional claims as explained here.
Everything works fine with Microsoft Account. But I am facing issues with Local Account Sign in.
email claim is only populated when the user signup but not on sign-in. In case of sign-in the email is part of "signInNames.emailAddress" claim. I tried making changes as explained here and here. I would like the email to be populate in email claim as my API uses this claim.
Additional calims returned from my REST API are not added to token only for Local Login. They are added for Microsoft Account.
thank you.
Update: For point 2, its a problem with my policy file and is now fixed.
There is a simple method to return email claim.
Just replace <OutputClaim ClaimTypeReferenceId="email" /> with <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" PartnerClaimType="email" /> in your SignUporSignIn.xml file.
You need to sign up new local user and then sign in to test it. You will see the email claim.
In fact, this solution has been provided by #Wayne Yang in the post you shared.
I'm using custom policies with a CombinedSignInAndSignUp for social accounts and LocalAccountSigninEmailExchange.
Using the domain_hint I can skip the selection for social accounts and go directly to e.g. google sign in.
I also want to set domain_hint to "LocalAccount" and then ONLY show the local account sign in.
I guess I can do that by adding a first step in the UserJourney to check if domain_hint="LocalAccount" and if the ClaimEquals skip the social providers.
I can get the value as output claim when I specify:
<OutputClaim ClaimTypeReferenceId="domain_hint" AlwaysUseDefaultValue="true" DefaultValue="{OIDC:DomainHint}"/>
But how do I get the value as Precondition in an OrchestrationStep???
You can use the {OIDC:DomainHint} claims resolver.
I’m currently trying to follow the guide here to setup our AADB2C IDProvider as a RP to Salesforce using Saml2.
Although the initial few steps are ok…
The new salesforce button is displayed in the login page.
When pressed leads me to the salesforce login page
I can login into salesforce.
The issue occurs when I am redirected back to AADB2C:
https://login.microsoftonline.com/te/{tenantname}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/as
results in a 404 File or resource not found.
Do you know if this is the correct url to redirect back to AADB2C?
I’ve tried to use App Insights analytics (trace) but cannot find any issue in there (I believe because the issue is not logged as the resource not found)
On the bigger picture, my base custom policy is setup for openid, but this salesforce policy is setup to follow a user journey that consumes saml2 … how does that work for it to be able to understand both protocols?
If I change setup on the RP policy from openid to saml2
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2" />
I can then access to saml metadata on that policy, but I lose capability of testing it up using Azure dashboard. Is there a way I can test it then?
Any help will be appreciated.
Yes, you need to set up the certificate in aadb2c. Also, you need to ensure that the Reply URL and Redirect URIs are matching, and the App ID matches the Client ID.
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.