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.
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 have two different redirect URIs in my webapp like localhost:4200 and localhost:4201. Trying to have single-sign-on for these two. Based on this document https://learn.microsoft.com/en-us/azure/active-directory-b2c/session-behavior?pivots=b2c-custom-policy#configure-azure-ad-b2c-session-behavior, I
changed my session behavior and SSO configurations and added a UserJourneyBehaviors element inside of the RelyingParty element. It still asking to sign-in localhost:4201, though i have signed in localhost:4200
<UserJourneyBehaviors>
<SingleSignOn Scope="Tenant"/>
<SessionExpiryType>Absolute</SessionExpiryType>
<SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
<ScriptExecution>Allow</ScriptExecution>
</UserJourneyBehaviors>
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.
Why we need multiple token requests:
We're using implicit flow for our SPA to get access tokens from Azure AD B2C to access APIs that are protected by the B2C. We need to access multiple APIs and those are all registered as different applications in B2C, hence different audience for each. Since they are all different audience, B2C doesn't support a single token request for multiple audiences, so we'd have to make multiple token requests.
Background on B2C setup
We support local account login, as well as social login which is using our other Azure AD identity provider. We're also using custom policies for our B2C (identity experience framework)
The issue
The issue happens for user using the Azure AD login social login. The user has logged in before.
When multiple requests are made, we noticed the following network trace in google chrome:
The trace above showing:
Line 1 & 2 are the token request to B2C authorize endpoint for 2 different api/scope/audience.
Line 3+4 & line 5+6, those are redirects to login.windows.net and login.microsoftonline.com both as 1 set for a particular api/scope/audience.
Line 7 & 8 are both the the response (id token) form post back to B2C. The line 7 returns a bad request response from the form post.
The questions
Why the need to redirect back to login.windows.net or login.microsoftonline.com? Since the user has logged in before, shouldn't he has a valid session and thus B2C can just return the token requested?
Can B2C support concurrent token request (or login) from the same browser for social login identity? We're suspecting this is due to the auth state that B2C expect from social login is only one and unique, so concurrent login causes this to override each other which then cause the other request to be invalid. There is no details at all on the bad request response. It just shows a blank page with "Bad request" text.
-- Update March 5th, 2019 --
After some tinkering on B2C custom policies, I've managed to suppress the redirects, after having logged in once, by changing the following:
<TechnicalProfile Id="SM-SocialLogin">
<DisplayName>Session Mananagement Provider</DisplayName>
<!--Changed to this provider instead of ExternalLoginSSOSessionProvider-->
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" />
<PersistedClaim ClaimTypeReferenceId="objectId" />
... removed for brevity ...
<PersistedClaim ClaimTypeReferenceId="groups" />
</PersistedClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
</OutputClaims>
</TechnicalProfile>
Changes made is to use default session provider.
Why the external session provider would not suppress re-authenticating though? The metadata AlwaysFetchClaimsFromProvider set to false would not suppress re-authenticating as well.
But going with this workaround cause us another problem which is asked in a separate question.
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.