I have a multi tenant enterprise app. It authorises a few graph API permissions when installed and has SAML SSO configured. The whole idea is that my customers can install this and in one process grant my application access to their tenant, and setup SSO for that customers users.
The graph API permissions work totally as expected, I get the needed access to the tenants who installed the app.
Then there is the SAML SSO part. That's just totally not working. In my test tenant where I installed my app, it says that the app has SAML SSO and that it is only application owner who can configure - all fine.
I then try to log in (to the web app using this SSO configuration) with a user from my test tenant - no luck!
First I thought that it had to do with the user not being assigned the app, but it complains the the application in tenant A is not available for user in my test tenant and the user should be added to tenant A. That of course is not a solution since I want to use this for customers.
So right now I am stuck with 2 app's. One gallery app for SAML SSO and my app granting API permissions. It works, but it just seems SO stupid. Isn't there a better way?
Azure AD SAML applications are not intended to be multi-tenant, this is why you need to invite external users as guests.
It's worth to mention it's possible for an Azure AD app to support both OIDC/OAuth2 and SAML and thus rely on the same session cookie to obtain an access token for MS Graph.
If you need multi-tenancy, you should use modern protocols such as OpenID Connect for authentication and OAuth2 for authorization. MS Graph relies on JWT access token anyways.
Related
For my current ASP.NET Core MVC application I authenticate directly with a web app registered in Azure AD Portal. This provides me with an access token so on the backend of my web application I can use MS Graph with my users specific account (ie add files to their onedrive , email, etc). However, my organization also has Okta which a lot of applications authenticate against. So I was trying to determine to authenticate through Okta (which has a much cleaner sign in process IMO) as well as authenticate against Azure AD and get an access token. Through my research I found something in my web application registration in Azure AD called Workload Identity Federation. This led me to this useful video
https://www.youtube.com/watch?v=wZ0gCJYMUKI
and also microsofts info site:
https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation
This seems to answer what I want which is to use Okta but allow me to still use MS Graph for my users since it will authenticate against Azure AD (correct me if I am wrong and this is for something else). My issue is none of these resources really go into depth regarding how the access token is passed to my application so I can use MS Graph. My research this is called client credential flow since my application only has delegated permissions so it requires the users to log in and it basically allows my web app to act on their behalf when using MS Graph. So I am trying to understand and fill this void of information regarding how client credential flow fits into Workload Identity Federation and is this the solution to my problem.
I'm trying to write an R package to let users access the files in their OneDrive folders from R. The API is Microsoft Graph.
Everything is working fine with OneDrive for Business (which is basically SharePoint under the hood, as I understand it). However, I can't get it to work with personal OneDrive.
Custom app registration, consumers authorization endpoint
When I use an app registration under my own AAD tenant, I get the following error from the consumers AAD authorization endpoint:
AADSTS50020: User account 'xxxxx#gmail.com' from identity provider 'live.com' does not exist in tenant 'Consumers' and cannot access the application 'd44a05d5-c6a5-4bbb-82d2-443123722380'(AzureRtest_cli) 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.
Custom app registration, 9188040d-6c67-4c5b-b112-36a304b66dad endpoint
From this page it appears that the token should be for the tenant 9188040d-6c67-4c5b-b112-36a304b66dad instead of the generic consumers. When I tried that, I obtained a seemingly valid token. However, talking to the https://api.onedrive.com/v1.0/drive endpoint results in a cryptic 401 error.
Azure CLI app registration, consumers endpoint
As a hack, I tried piggybacking off the Azure CLI's app registration. This fails with
AADSTS65002: Consent between first party application '04b07795-8ddb-461a-bbee-02f9e1bf7b46' and first party resource '00000003-0000-0000-c000-000000000000' must be configured via preauthorization. Visit https://identitydocs.azurewebsites.net/static/aad/preauthorization.html for details
Azure CLI app registration, 9188040d-6c67-4c5b-b112-36a304b66dad endpoint
Finally, I tried using the CLI app registration with this tenant, which also failed:
unauthorized_client: The client does not exist or is not enabled for consumers. If you are the application developer, configure a new application through the App Registrations in the Azure Portal at https://go.microsoft.com/fwlink/?linkid=2083908.
What are the exact steps I need to do to get to my personal OneDrive?
It turns out I had a bug in my code: I was using the tenant consumers.onmicrosoft.com instead of consumers. The process to communicate with Graph for personal OneDrive that worked for me was:
Use the authorization code flow as described here, with the following specs:
tenant: consumers
client id: for my custom app registration
scope: https://graph.microsoft.com/{scope} offline_access openid where the scope is one of those listed here
Use the API endpoint https://graph.microsoft.com/v1.0.
With regard to that last point, note that the documentation here is incorrect or at least outdated, as it still gives https://api.onedrive.com/v1.0 as the endpoint for personal OneDrive requests.
Azure B2B gives simple steps for direct federation with google and facebook.Though, i don't see any documentation to establish direct federation with Auth0 or Okta. I tried myself with Auth0 at the time or invitation my user succesfully login with auth0 account but after redirection to invitation.microsoft.com getting redemtion failure.
Can someone give me steps to setup Auth0 as IDP and then configure that with Azure AD direct federation.
https://auth0.com/docs/protocols/saml-configuration-options/configure-auth0-as-saml-identity-provider
i have already setup everything as mentioned in above document but still not able to redeem invitation after login.
Any help would be highly appreciated!!!
Azure AD B2B can be configured to federate with identity providers that use the WS-Fed or SAML. There is no specific Document for direct federation either from OKTA or Azure. From Azure end Direct federation is only allowed for policies where the authentication URL’s domain matches the target domain, or where the authentication URL is one of these allowed identity providers as per this document. I recommend you to open a support case with Auth0 since it involves multiple parties.
I have included SSO (SAML) authorization in my existing application. But for me it was an unpleasant surprise to find that only 2 types of users can use the login through the providers I added (Okta, Azure AD):
Users who are located in the corporate directory of the provider (for example, I made an application on my account, there are no more
users. This means that any other user will not be able to use the
login form, because he is not a member of my tenant)
Third-party users of companies, whose administrators have added a
template of my application from the general list and connected their
users to it.
I expected other results, I need ANY user to be able to log in through these providers (regardless of whether he is in the corporate directory or has his own separate account that is not integrated into my application)
I thought about changing the SAML protocol to OIDC (OpenID Connect), but it seems to me that everything will work in the same way (at least Azure AD, because it seems there are no other options for working with it, except for corporate distribution)
Who had a similar experience, could you tell me what I should use among technologies and protocols so that ABSOLUTELY ANY user can log into my application through Okta / Azure AD / Google? Thanks!
Azure AD login fail screen
Okta login fail screen
You can use Azure AD OAuth2 flows and multitenant apps with MSA (personal account) support to allow any user from any domains and personal accounts to login into your application. Or you can switch to Azure AD B2C (which also relies on OAuth2) to connect different identity providers (Local Azure B2C, Azure AD, Facebook, Google, Amazon, Github, Linked in, Twitter, generics, etc) and allow all their users to login into your application.
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.