Problem
We are successfully using our ADB2C tenant as an identity provider for our Azure API management instance.
Several months ago we integrated a B2C custom domain thanks to Azure Front Door. We now want to no more use the xxxx.b2clogin.com endpoint for the authorization endpoints within APIM B2C identity but instead our B2C custom domain.
The problem is that I'm unable to update the authority endpoint with my custom domain url. It always leads to an "Azure Active Directory B2C authority is not valid." error.
**Question**
How can we handle this? We clearly want to use our B2C custom domain in order to benefit from our FrontDoor features, and also to block (at B2C side), in the future, all the signin attempts that will target the b2clogin.com domain.
Edit
Seems my question was not so clear! To resume, I'm just trying to update the settings of my ADB2C IDP within the APIM identities blade, in order to use our B2C custom domain instead of the [tenantname].b2clogin.com.
This IDP is already functional for a long time now on the b2clogin domain, we now want to align the APIM with the implementation of the custom ADB2C domain. There is clearly no action to do on our ADB2C app which is already well configured.
In this picture below, we simply tried to change the Authority field from [myb2ctenant].b2clogin.com our custom B2C domain (sample here is mylogin.customdomain.com)
As far as I remember it was already a mess when we had to switch for login.microsoftonline.com to the b2clogin url :(
APIM currently has does a validation check for onmicrosoft.com for B2C Login Tenant and .b2clogin.com for B2c Login Authority. This validation results in the Azure Active Directory B2C authority is not valid. error if anything but those domain names are used.
The feature is being discussed but would be in the min. 4 to 6 month timeframe if it makes it into the product.
New releases can be tracked here.
https://github.com/Azure/API-Management/releases
Related
I configured a new Azure AD B2C Tenant for testing purposes. I am trying to follow the example to use Azure AD B2C with Android.
https://github.com/Azure-Samples/active-directory-b2c-android-native-appauth
I created beside the B2C Tenant already a User Flow for the login.
During the authentication flow the app wants to read the "well known openid configuration" for my User Flow
https://login.microsoftonline.com/geomobilestage.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_login_signin
but the URL returns a 404 error. But when I try the following URL to read the configuration I receive http status 200
https://geomobilestage.b2clogin.com/geomobilestage.onmicrosoft.com/B2C_1_login_signin/v2.0/.well-known/openid-configuration
The URLs are public so everyone can try to call them in the browser to see the result.
So the configuration itself exists and seems to be ok. I have already another Azure AD B2C tenant and when I try to call the first URL for this tenant everything is fine. It seems to be that I am missing some configuration in the Azure portal but I really have no idea what I am missing and even where to look.
Regards
Michael
For Azure AD, see here:
https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration
For Azure AD B2C, see here:
https://{domain-name}.b2clogin.com/{domain-name}.onmicrosoft.com/{policy}/v2.0/.well-known/openid-configuration
The key thing here is to realize that the b2c config endpoint has a reference to a policy in it, otherwise it’s likely AAD.
We need to configure okta as IDP for azure ad applications. For example: When a user tries to access the enterprise application, they'll be challenged with a login page, which will be validated by OKTA. Post this authentication, the authorization will be handled by Azure and upon successful authorization, user will be shown a landing page of the application.
We have referred below links as reference for setup:
https://learn.microsoft.com/en-us/azure/active-directory/b2b/direct-federation
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-saml-idp
https://developer.okta.com/docs/guides/custom-url-domain/overview/
What we did so far?
Registered company "example.com" in okta. By default okta configures it as "example.okta.com"
Registered custom domain "id.example.com". Our okta instance is accessible using this domain
Created an enterprise SAML app (which also exist in Azure AD) in OKTA
Exported OKTA IDP metadata
Now, we are trying to import this IDP metadata as external identity provider in AAD. But it fails with below error, if we map example.com or id.example.com as domain name of federating idp. Because of these errors we’re unable to setup the custom domain of federated IDP(OKTA). Please assist us on the approach for the same.
Error Messages:
For domain as "id.example.com"
Failed to add a SAML/WS-Fed identity provider.This direct federation policy does not pass one or more requirements. Go to aka.ms/b2b-direct-fed to learn more.
For domain as "example.okta.com"
Failed to add a SAML/WS-Fed identity provider.This direct federation configuration is currently not supported. The authentication URL must match the domain for direct federation or be one of the allowed domains. Go to aka.ms/b2b-direct-fed to learn more.
You need to go through the Azure AD federation compatibility list to learn about how to federate an Azure AD tenant with a 3rd party IDP like Okta and others.
#Kalyan Krishna
Hi,
Thanks for the reply. We have already gone through the documentation. OKTA is listed down as one of the supported 3rd party federated IDP that Azure supports. We referenced the MS docs and tried to configure, but we observed Azure AD doesn't support external IDP(OKTA) configuration with custom domain. It throws error as mentioned in the above post. So, we tried to configure the federated domain as ".okta.com" (including other IDP metadata details). It worked then, and for authentication AZ AD is getting redirected to OKTA. SP authentication flow works fine when myapps URL is appended with tenant ID, but while testing IDP initiated SSO it fails.
IDP initiated SSO fails with OKTA as an IDP in Azure
I am a bit confused by the wording on the announcement for the deprecation of login.microsoftonline.com for "B2C tenants".
New tenants created after this announcement will no longer be able to accept requests from login.microsoftonline.com.
My main concern is: How will this affect the client credentials grant? As far as I can see, this is only supported via login.microsoftonline.com.
Although client credential flow is not currently supported by Azure AD B2C, you can set up client credential flow using Azure AD. An Azure AD B2C tenant shares some functionality with Azure AD enterprise tenants. The client credential flow is supported using the Azure AD functionality of the Azure AD B2C tenant.
Will the "Azure AD functionality" continue to work with login.microsoftonline.com indefinitely? If so, where can I draw the line of what this actually means?
I have created a new B2C tenant after the announcement. So far, everything works, even the B2C user flows via login.microsoftonline.com. The only difference at the moment is that I don't get the domain selection when I click on "run user flow".
My current understanding would be that "everything that uses B2C policies must use b2clogin.com" - everything else must continue to use login.microsoftonline.com.
Without policy:
https://login.microsoftonline.com/mytesttenant.onmicrosoft.com/oauth2/v2.0/token => working URL
https://mytesttenant.b2clogin.com/mytesttenant.onmicrosoft.com/oauth2/v2.0/token => 404
With policy:
https://login.microsoftonline.com/mytesttenant.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_signupsignin => working URL
https://mytesttenant.b2clogin.com/mytesttenant.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_signupsignin => working URL
(my tenant is not actually named mytesttenant)
I think you will still be able to use client credentials flow in Azure AD B2C tenant.
The deprecation of login.microsoftonline.com just affects the Azure AD B2C functionality.
However, the client credentials flow is an Azure AD functionality, it should not be affected, the B2C tenant just shares the functionality with the normal Azure AD tenant.
I have created a new B2C tenant after the announcement. So far, everything works, even the B2C user flows via login.microsoftonline.com. The only difference at the moment is that I don't get the domain selection when I click on "run user flow".
I suppose we can but we should not do this, as the UI has been changed, MS should not want the new users(create B2C tenant after the announcement) of Azure B2C to use login.microsoftonline.com, the implementation has not been changed, it will give other users a transition period.
I got an official answer back via Github.
Use of b2clogin.com is enforced for b2c functionality only. Client Credentials flow is not supported for B2C Applications. Since the App registered via App Registration under Azure AD B2C, can also be used for standard Azure AD as well which supports Client Credentials flow. For standard AAD functionality, use of b2clogin.com is not applicable and requires login.microsoftonline.com only.
For more details, refer to: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-apps#daemonsserver-side-applications
I'm building an ASP Net Core 2.1 website using Azure AD B2C based on this example code. However, I am using the Microsoft-recommended b2clogin.com domain because the microsoftonline.com domain is being deprecated.
During signup, after the identity provider authenticates successfully, it should redirect the user to an Azure AD B2C generated page where the user fills in some additional fields. Those fields drawn from the standard attributes offered by Azure AD B2C (i.e., I haven't defined any custom attributes). Everything works as expected with Microsoft Account authentication.
However, when authenticating against Google, there is no redirect back to that Azure AD B2C generated page. Instead, the user is sent to the default page of the site.
I thought I set the proper redirect uri in the Google Cloud Console:
But since the redirect is not working, I'm wondering if I need to set it somewhere else.
Turns out the problem was caused by the fact that I had completely filled out the custom attributes page when logging in via the Google identity provider, but not the Microsoft Account identity provider. So all Google cared about was authenticating me, and then tossing me back to my app.
Microsoft, OTOH, needed me to fill out all the required custom fields, so it sent me to the custom attribute page.
I had mistakenly assumed authentication always took me to the custom attribute page, but that's not the case.
We have a Web App secured with Azure AD B2C using custom Identity Experience Framework policies to allow users to register and sign in with social identities (Microsoft, Google, Facebook), or with an identity from another federated Azure AD instance, or with 'local' Email / Password accounts.
All the social accounts and the Federated AD work correctly. Sign up and sign in with Email/Password was working correctly, but we are now experiencing an error. We haven't knowingly made any changes to our Email/Password configuration since this was last known to be working, so we're not sure how this has happened.
The issue is: Sign Up with a new Email Address works correctly, and after the process completes, the user is correctly logged-in, and their account appears in the directory. If the user signs out, however, then any attempt to sign back in again fails:
(Email address shown is not the actual one. Error has been repeated by multiple users with new and old email/password combinations.)
Digging into the portal, the underlying error is revealed as:
70001 The application named X was not found in the tenant named Y. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.
This error appears sometimes to be related to a failure to grant permissions to an application in the portal. We have tried removing and reinstating all permissions, and re-granting permissions. This has not solved the issue.
Does anyone know what could be causing this issue, and in particular why sign up / sign in works correctly, but returning sign in does not?
UPDATE:
Just to confirm that we have the IEF and Proxy IEF apps configured in the AD directory:
And we have the login-NonInteractive technical profile configured in TrustFrameworkExtensions.xml:
Having wired up Application Insights (following these instructions https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-troubleshoot-custom), we're able to get to this more detailed error:
AADSTS70001: Application with identifier
'ProxyIdentityExperienceFrameworkAppID' was not found in the directory
weapageengine.onmicrosoft.com
The only place 'ProxyIdentityExperienceFrameworkAppID' appears in any of our custom policies is shown in the XML snipped above, but this seems correct as per the documentation here: https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/3b4898fec3bf0014b320beffa6eb52ad68eb6111/SocialAndLocalAccounts/TrustFrameworkExtensions.xml#L38 - unless we are meant to update those 'DefaultValue' attributes as well?
Resolution:
As per the answer below, it is necessary to update both the Metadata and the default values with the relevant app ids. Worth noting that in the GitHub sample https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/3b4898fec3bf0014b320beffa6eb52ad68eb6111/SocialAndLocalAccounts/TrustFrameworkExtensions.xml#L38 the boilerplate values are differently cased, leading to our missing one in a replace-all:
The local account sign-in authenticates the end user against the Azure AD B2C directory and then reads the user object from it.
The local account sign-up and the social account sign-in do not authenticate the end user against the Azure AD B2C directory. The local account sign-up writes the user object to it. The social account sign-in delegates authentication to the social identity provider and then either writes the user object to the Azure AD B2C directory if the user object does not exist or reads the user object from the Azure AD B2C directory if the user object does exist.
To enable authentication of the end user by the local account sign-in against the Azure AD B2C directory, you must add the Identity Experience Framework applications to the Azure AD B2C directory and then configure these IEF applications with the login-NonInteractive technical profile.
The local account sign-up and the social account sign-in do not require these applications.