We installed an enterprise application through the Azure AD App Gallery. But when we try to config the Single Sign-on, it keeps saying:
The single sign-on configuration is not available for this application
in the Enterprise applications experience. HubSpot is a multi-tenant
application and the application is owned by another tenant.
Do we need to change some settings to allow the setup of Single sign-on?
We followed this tutorial but are now stuck on "Configure Azure AD SSO".
When added the hubspot application from Azure AD Enterprise application gallery like below ,you should be able to see if SSO setting is available or not and the ways it can be supported for sso.(Here i can be able to use SAML based SSO, or linked SSO)
Then you should be able to edit the saml configuration
For me when I search the hubspot app created in app registrations, its under supported account type of my organization only.
Please check if the App is registered and added as Multi-Tenant App in your case and users have to use login for particular tenant instead of common to avoid error.
Also user accounts need to be pre-provisioned into HubSpot prior to
sign-in .
Reference:
Sign in with My Apps portal and Azure AD SSO in multi tenants application - Stack Overflow
Related
I created an Application Registration on our Azure AD.
I then use the application registration id to create "Enterprise Application" in our customers' AD's.
It goes like this
Their admin sign into our system and clicks connect AD
We send a challenge (OpenId Connect) that allows them to sign into their microsoft account.
This creates our application under "Enterprise Applications" in their AD and it then workes fine with SSO
So far so good. But now we want to add the next logical step with Provisioning with Scim v2 however if I on a customer/test AD browse to our app under Enterprise Application and then click Provisioning I see the following
There is no way to hook up provisioning no matter if I support Scim2 as required.
Why is this? Does our app need to be in the gallery for this to work?
I noticed I can go to Enterprise Applications > New application > Non-gallery application and create a new application. This will then work with provisioning.
But then our customers would need two apps, one from our app registration that does SSO and one more for provisioning. I would like one app to do both.
Your app needs to be in the gallery to have provisioning enabled. Barring that, the only other option is what you've already described - a custom non-gallery app.
To get your app in the gallery, https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-howto-app-gallery-listing
We are building applications in ASP.Net MVC and Web API that use a range of OAuth 2 features - AcquireTokenByAuthorizationCode (using microsoft.identity.web), AcquireTokenSilently, AcquireTokenOnBehalfOf, AcquireTokenForClient for different parts of the application landscape.
The applications use MSAL.Net to interact with Azure AD and users provisioned in it to provide access to resources and that works ok.
We are now looking at building a connect back to the organization's on-prem maintained user accounts so the end users are not duplicated in AAD and on prem, so ADFS maintained in the org is an option. Considering the ADFS instance to be 2016, the one option to have MSAL.Net work with ADFS appears to be having Azure AD federated with ADFS as explained in this article:
https://learn.microsoft.com/bs-latn-ba/azure/active-directory/develop/msal-net-adfs-support
The article only discusses AcquireTokenInteractive and I do not see explanation that other MSAL.Net operations are supported on having AAD federated with ADFS. I would assume that is true, and we have to run through our tests after we have it all configured, but meanwhile,
would anyone have any experience or documentation around having the range of operations with MSAL.Net (and even msal.js) and AAD work OK when AAD is federated with ADFS?
So I went ahead and tried this for myself, setting a VM up in Azure, installed Active Directory, AD FS and configured the federation between Azure AD and the VM AD FS as per the article https://learn.microsoft.com/en-us/azure/active-directory/b2b/direct-federation-adfs.
Then validated the different OAuth features used by our application, specifically (I would expect other oauth features to work as expected too based on the below observations):
AcquireTokenByAuthorizationCode
AcquireTokenSilently
AcquireTokenOnBehalfOf
AcquireTokenForClient
All these feature work as expected. The user is redirected to org login page and redirected back to the application.
A couple of observations along the way
The refresh token lifetime is 12 hours when working with On premise AD credentials integrated via ADFS instead of the few days when user is provisioned in AAD. This is apparently to mitigat the risk of user information changing e.g. password change. If the browser is idle for > 12 hours, re-login by the user is required.
Once authenticated, further OAuth operations do not involve On prem AD / ADFS. The operations are against Azure AD, any browser redirects are to Azure AD for re-auth.
I'm working on an application that has an angular 6 front end and a .net core 2.0 back-end and am trying to set it up so that my application authenticates users via Azure active directory. The issue is that I want the .net core back-end to do all the authentication programmatically when I have the front end pass an email and password. Everything that I've seen so far online suggests to have the front end redirect to the Microsoft login page but we are using our application as a boiler plate project and want to be able to change the type of authentication easily in the back-end without having to change the angular front-end. Does anyone know how I could go about this?
You can use Resource Owner Password Credentials Grant .The process will like that you collect the user credentials in Angular app and post to .net core back end , then finish the authentication in back-end app with user's credential. But that is not recommended because The ROPC flow requires a high degree of trust and user exposure and you should only use this flow when other, more secure, flows can't be used.
Also :
The Microsoft identity platform endpoint only supports ROPC for Azure AD tenants, not personal accounts. This means that you must use a tenant-specific endpoint (https://login.microsoftonline.com/{TenantId_or_Name}) or the organizations endpoint.
Personal accounts that are invited to an Azure AD tenant can't use ROPC.
Accounts that don't have passwords can't sign in through ROPC. For this scenario, we recommend that you use a different flow for your app instead.
If users need to use multi-factor authentication (MFA) to log in to the application, they will be blocked instead.
Reference : https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
Scenario:
(Azure-hosted) Web App. Users should be able to sign in to my app using a Microsoft Account (i.e. #live.com, #hotmail.com, etc accounts) that has one or more Azure subscriptions. The application would then allow them to view and manage their Azure resources in specific ways through my app.
Points of confusion/frustration:
ADAL vs MSAL for authentication
Azure AD vs Azure AD B2C for the tenant hosting the application
Where do you register the tenant app? In the AD B2C under "App Registrations"? In a regular AD under "App Registrations (Preview)"? On the App Registration Portal (i.e. apps.dev.microsoft.com)?
Which of the above client ID & secret do you use in the web app (in the .config file)?
The documentation for none of these seem to cover the scenario end-to-end and most of it is completely out of sync with other developments.
I am hoping here to get some point of guidance from other developers that have actually gone through this journey themselves (rather than folks that just read the documentation). In specific, I am hoping to get answers from the Azure CXP team that monitors these questions and provides official & supported answers.
Your scenario requires access to Azure APIs, thus you have to make the logins against "regular" AAD, not B2C.
You can't make your logins against MSA accounts directly as they must be members of an AAD to have access to subscriptions.
You can use either ADAL or MSAL to handle the authentication.
Note you must use v2.0 endpoint for MSAL and the "v1" endpoint for ADAL.
See limitations of the v2 endpoint here: https://learn.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison.
You register it under Azure portal -> Azure Active Directory -> App registrations.
You can also use the preview version if you want.
You will need the application id (= client id) + a key (secret) from the app registration.
I created a "Web app / API" app in our organization's "xxx.onmicrosoft.com" Azure Active Directory. The app's "Multi-tenanted" property has been set to "Yes".
We configured OpenID Connect (we use https://github.com/mitreid-connect/) to use the following URLs:
https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token
Please note that we used "common" in the URLs and we didn't use "xxx.onmicrosoft.com" because we want people from outside "xxx.onmicrosoft.com" to be able to authenticate and access our app.
With those settings, the people from xxx.onmicrosoft.com can properly authenticate and access the app.
However, when I use my personal live.com account (with username xxx#gmail.com) to access the app, I get AADSTS50020 error. I am able to properly authenticate with my xxx#gmail.com account, but I do not get redirected to the Reply URL. I'm stuck on Microsoft's Web page with the following error msg:
AADSTS50020: User account 'xxx#gmail.com' from identity provider
'live.com' does not exist in tenant 'xxx.onmicrosoft.com' and cannot
access the application '391e7103-ZZZZ-zz87-xxxx-7xxxxxd5xxxx' in that
tenant. The account needs to be added as an external user in the
tenant first. Sign out and sign in again with a different Azure Active
Directory user account.
What configuration do I need to change if I want people from any identity provider to be able to access my app ?
Like it has been stated here, I expected that people from anywhere could access my app without requiring more configuration on my side.
I'm asking this question because I'm in the process of getting certified for AppSource and this currently blocks me from being able to do so.
AppSource only requires work accounts to sign-in. You are using an #gmail account - which is a personal account - and because you are using the Azure Active Directory v1 endpoint in addition to common (https://login.microsoftonline.com/common), it can't accept personal accounts to sign-in directly - only work accounts.
You have three options:
If sign-in personal accounts is not a requirement for your application, then you can continue using the v1 endpoint and use a work account to sign-in/test your application. This will make you ready for AppSource certification.
If you need/ want to allow personal accounts in your application in addition to work accounts, then you can consider using the v2 endpoint (https://login.microsoftonline.com/common/v2.0) for Azure Active Directory. The v2 endpoint allow both personal accounts and work accounts to sign-in with no effort.A note is the v2 endpoint has some limitations: if you can live with these limitations (for example, your application only needs to sign-in users and eventually make queries against Graph API), then in general it should be fine to use, but if you need extra features like protecting your own Web API with scopes, then this feature is not released at this point (as November 2017). Please read this document for an updated list of limitations of the v2 endpoint.
A third (but less recommended option for AppSource) is to keep using the v1 endpoint and make your application to be single tenant - which is to change the endpoint from https://login.microsoftonline.com/common to https://login.microsoftonline.com/{yourtenantid}, and then use B2B invitations API to invite every external users (including work and personal accounts) to be part of your Azure AD tenant/organization. More information about B2B here as well.
The option '3' above have some consequences for management as well for AppSource: by using this option, you are required to have one Azure Active Directory tenant (if you don't have a tenant already, you can get one using these instructions), and the users being invited will be guests accounts of this tenant - this mean that you need to invite every external user to your application/ tenant. A multi-tenant application allows any user from any organization to sign-in to your application with less management on your side. In general for SaaS applications, multi-tenant configuration is recommended.
For AppSource, also the option '3' leads to a less-immersive user experience (Partner led trial), where the end user won't be able to access your application's demo right away - mainly because that they have to wait for the invitation's email and accept it (user has to accept being guest of your tenant) so that they can access your application.
For more information about AppSource requirements and trial options - please see this article.