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
Related
I have a requirement to build a web app that connects to a customer's API (authenticated as the user using the web app). This same web app will need to connect to our own internal API which is authenticated with B2C.
The problem is that each customer has their own authentication server (always Okta) and so I couldn't add an IDP for each customer in a custom policy because I'd have to add thousands and continue to add them.
Is there a way to get IDP configuration programmatically so that I can look up the correct Okta instance?
Any other suggestions are welcome.
I had limited chance to set up the above scenario and test in lab.
Add the app in Okta and set the below parameters, instead of adding app in AAD.
Login redirect URI: https://{yourb2ctenantname}.b2clogin.com/{yourb2ctenantname}.onmicrosoft.com/oauth2/authresp
Change the following settings in the B2C Claims provider
Okta OpenId Connect Settings in B2C Policy:
ProviderName: https://{yourOktaTenant}/oauth2/default
METADATA: https://{yourOktaTenant}/oauth2/default/.well-known/openid-configuration
Reference Link: Use below link for custom policies in B2C:
https://github.com/mleziva/azure-b2c-okta-custom-policy
I am very new to SSO and am having trouble enabling cross company SSO. I work on a React SPA and used the MSAL React Library to implement SSO for our application. I created a non-gallery Enterprise Application in Azure, and used that subscription information to validate users on the application during login. This is all working as expected.
After providing our SAML SSO configuration to companyB, the user at companyB cannot sign on and is getting the following error...
"Selected user account does not exist in tenant 'XYZ' and cannot access the application '123-456-789' in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account."
To me, that means I need to manually add the user who is attempting to log in, but that would negate the usefulness of integrating the two Azure ADs. I've provided all of my SAML configuration to companyB, and still no luck. What could I be missing?
In order to create the link between the two Azure ADs, the user just needs to create a non gallery application with SAML SSO enabled and the SAML config, right? Any insight into this issue would be greatly appreciated!
I realized my code was configured to only work for one tenant, pointing to the common login endpoint solved this issue.
I am working on setting up Tableau server. I want end users who login with their Azure AD B2C credentials to see some of the visualizations we build in Tableau.
While setting up Tableau, I noticed that Tableau works with Azure AD Domain services only. Two of our user groups in Azure AD is synched with ADDS. So I am able to add those users to Tableau.
However, I do not see similar synchronization option between ADDS and AD B2C.
Question: ADDS is only for Azure AD and not for AD B2C? Any suggestions to achieve my goal mentioned in first two lines?
From official documentation
Azure Active Directory Domain Services (AD DS) provides managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos/NTLM authentication. You use these domain services without the need to deploy, manage, and patch domain controllers (DCs) in the cloud.
it is meant as a mean to help customer that are using active directory on premise to migrate their domain controllers to Azure domain services and still support authentication and traditional management using OU, LDAPS and Kerberos.
https://learn.microsoft.com/en-us/azure/active-directory-domain-services/overview#:~:text=Azure%20Active%20Directory%20Domain%20Services%20(AD%20DS)%20provides%20managed%20domain,(DCs)%20in%20the%20cloud
Azure B2C
Azure Active Directory B2C (Azure AD B2C) is an identity management service that enables custom control of how your customers sign up, sign in, and manage their profiles when using your iOS, Android, .NET, single-page (SPA), and other applications.
basically this is meant to support modern authentication for applications using OIDS,OAuth2, SAML
https://learn.microsoft.com/en-us/azure/active-directory-b2c/#:~:text=Azure%20Active%20Directory%20B2C%20(Azure,SPA)%2C%20and%20other%20applications.
so you cannot use AADS (Active Directory) to manage B2C authentications.
to configure Tableau with Azure Active Directory I suggest you use SAML as described in official documentation:
Tableau SAML
https://help.tableau.com/current/server/en-us/saml.htm
Azure B2C SAML
https://learn.microsoft.com/en-us/azure/active-directory-b2c/connect-with-saml-service-providers
you should have something like the below
User navigates to the Tableau Server sign-in page or clicks a published workbook URL.
Tableau Server starts the authentication process by redirecting the client to the configured IdP (Azure B2C).
Azure B2C requests the user’s username and password from the user. After the user submits valid credentials, Azure B2C authenticates the user.
Azure B2C returns the successful authentication in the form of a SAML Response to the client. The client passes the SAML Response to Tableau Server.
5.Tableau Server verifies that the username in the SAML Response matches a licensed user stored in the Tableau Server Repository. If a match is verified, then Tableau Server responds to the client with the requested content
We have configured OKTA as an IDP in Azure AD. While testing the IDP(OKTA) authentication flow, it throws error.
Configured Okta & Azure AD using below microsoft link as reference.
https://learn.microsoft.com/en-us/azure/active-directory/b2b/direct-federation
What we did so far?
Registered company "example.com" in OKTA.
Created a custom SAML app in OKTA to export the OKTA IDP metadata
Configured the app SSO settings as above reference link
Imported OKTA metadata as external IDP in AzureAD
Followed below steps to test IDP Authentication Flow
Logged in with the existing user in OKTA
After successful authentication, user is redirected to dashboard page
Here, when we click on custom app chiclet, instead of getting redirected to Microsoft apps portal, it throws below error -
AADSTS50107: The requested federation realm object 'http://www.okta.com/xxxxxxxxxxxxxxxxxxxx' does not exist.
i think direct federation doesn't support idp initiated login, you need to login using tenant context.
have you seen that note in the link you pasted ?
Direct federation guest users must sign in using a link that includes the tenant context (for example, https://myapps.microsoft.com/?tenantid= or https://portal.azure.com/, or in the case of a verified domain, https://myapps.microsoft.com/\.onmicrosoft.com). Direct links to applications and resources also work as long as they include the tenant context. Direct federation users are currently unable to sign in using common endpoints that have no tenant context. For example, using https://myapps.microsoft.com, https://portal.azure.com, or https://teams.microsoft.com will result in an error.
I am getting an error message when trying to connect to Dynamics 365 environment from my application.
Exception Message : Metadata contains a reference that cannot be resolved: 'https://adfs.domainname.com/adfs/services/trust/mex'.
What i am trying to find out is the physical appearance this url(https://adfs.domainname.com/adfs/services/trust/mex) in Azure ADFS. I am a beginner in Azure.
Does this url exists in azure or is it something like a datapoint?
The endpoint you are looking at is not an Azure endpoint. It is an ADFS endpoint and Azure uses it in scenarios, where your custom domain is federated with your on-premise ADFS server for authentication.
Let's assume you have a domain called carnival.com verified in Azure and you have users who are synchronized from your on-premise AD, user1#carnival.com, user2#carnival.com etc. Now if you federate carnival.com with your ADFS in the on-premise environment, then Azure AD will redirect the users to ADFS endpoints when authentication is required.
It looks like the information provided while configuring the ADFS is wither wrong or your ADFS is currently not reachable. Ideally when you navigate to that endpoint, it should display an XML as shown in this article.
Try checking if the authentication to Azure AD is working for the domain in question and check with your ADFS team to troubleshoot this further.