How can access claim value from a previously populated claim in a custom html page?
I have tried specifying a claim as a <UserInputType>Readonly</UserInputType> and then marking it as an output claim of my TechnicalProfile that uses the custom html pahe like so
<OutputClaim ClaimTypeReferenceId="labsobject" />
This makes the readonly input show up but the value that shows in the box is labsobject as opposed to the actual value of the claim. Accessing the value through JS also shows an empty string.
I confirmed the claim has value as it is later correctly embedded into the token.
To prepopulate claims on a selfAsserted technical profile, add them first as an input claim, then as an output claim to display on the screen.
Related
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
I created my Azure AD B2C custom policies to authenticate users.
I also added a custom attribute to ask the user for a unique information, something like the SSN.
I've already set the custom attribute as required and I put a restriction based on a regex, but I can't find a way, in the docs, to verify if the value already exists in the directory and give an error if that condition is true while the user signs up.
In this question, the suggestion is to call a rest api that uses Microsoft Graph Api to verify if the value set to the custom attribute already exists:
Azure B2C: Querying AAD using a custom claim?
Is it the only solution or, meanwhile, has been released a way to do this check directly from Azure AD B2C custom policy?
Add a technical policy like:
<TechnicalProfile Id="AAD-UserReadUsingEmailAddress">
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="extension_attribute"/>
</OutputClaims>
</TechnicalProfile
This "merges" with the TP in the base so that when your policy reads AAD, it will also read your extension attribute.
Then in your user journey add a precondition of "ClaimsExist".
I want to pass a parameter via the request URL to B2C and then be able to send this out as a claim in the access token. I am guessing I will need to capture this in a claimType. How do I go about this?
Thanks!
You can capture query string parameters using a Claims Resolver.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/claim-resolver-overview#oauth2-key-value-parameters
For example, if you would like to capture the ?bandz=test query string parameter, you could resolve that via the {OAUTH-KV:bandz} claims resolver.
In your <RelyingParty>'s output claims, you could then refer to a claim and the value like this:
<OutputClaim ClaimTypeReferenceId="customClaimId" AlwaysUseDefaultValue="true" DefaultValue="{OAUTH-KV:bandz}" />
You would just need a Claim definition for customClaimId.
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 working on a REST API that sends a confirmation email for a custom policy. Can anyone tell me if there is a way to pass the current culture so I can send a localized email?
You can add an <InputClaim /> to the REST API technical profile for passing the current culture as follows:
<InputClaim ClaimTypeReferenceId="mkt" PartnerClaimType="mkt" DefaultValue="{Culture:RFC5646}" />
where "mkt" (market) is an example of a claim type that you can replace with your own one.
"{Culture:RFC5646}" is known as a claims resolver.
Be sure to add the claim type to the TrustFrameworkPolicy/BuildingBlocks/ClaimsSchema section.