Azure AD multi-tenant app unpredictable behaviour?
up vote
2
down vote
favorite
I am trying to build a scalable multi-tenant b2b SAAS in Azure AD using Angular in the front end and node + Azure MS SQL sharded db design.
I've spend a week going through the MS documentation and examples (tailspin, survey apps) and have started testing the multi-tenant behaviour in an angular7 app that has nothing other than authentication with adal-angular4 on it which I've used for ~5 other projects that are currently in production.
So far, I can't for the life of me figure out the reason behind this unpredictable behaviour. I have 3 tenants: A - B - C
A is the developer tenant + my admin account, B is another company's tenant + my normal user account and C is a AD Free tier tenant with my personal account.
I have done nothing else to my app in Azure AD on the developer AD other than switch that multi-tenant setting to on and changing Oauth2implicitflow to true.
If I login with Tenant A into the app, all is good, in the console I
can see tenant A's GUID under TID.If I login with Tenant B - it asks for permissions the first time and then lets me in (why??).
- If I login with Tenant C 'work' account it throws no errors, does not ask for permission, returns back to the page without actually being logged in and with nothing on the console.
- If I login with Tenant C 'personal' account it tells me the tenant live.com is not provisioned for the app.
My questions are:
- Why did it even let Tenant B to log into the app? They were definitely not provisioned to be able to access it and on the console the tid is clearly of the second tenant meaning (I think) that the account is NOT a guest on tenant A to be able to login.
- I have no idea why the tenant C throws no error on the Azure side but instead just returns back to the page without actually being logged in.
- Is there any documentation that I'm missing on which tenants can sign up into the app? I have looked at Tenant sign-up and onboarding article but it doesn't really address the issue.
Based on the documentation that I have read, the behaviour of Tenant B and C trying to log into the app makes no sense.
active-directory azure-active-directory multi-tenant activedirectorymembership
|
show 4 more comments
up vote
2
down vote
favorite
I am trying to build a scalable multi-tenant b2b SAAS in Azure AD using Angular in the front end and node + Azure MS SQL sharded db design.
I've spend a week going through the MS documentation and examples (tailspin, survey apps) and have started testing the multi-tenant behaviour in an angular7 app that has nothing other than authentication with adal-angular4 on it which I've used for ~5 other projects that are currently in production.
So far, I can't for the life of me figure out the reason behind this unpredictable behaviour. I have 3 tenants: A - B - C
A is the developer tenant + my admin account, B is another company's tenant + my normal user account and C is a AD Free tier tenant with my personal account.
I have done nothing else to my app in Azure AD on the developer AD other than switch that multi-tenant setting to on and changing Oauth2implicitflow to true.
If I login with Tenant A into the app, all is good, in the console I
can see tenant A's GUID under TID.If I login with Tenant B - it asks for permissions the first time and then lets me in (why??).
- If I login with Tenant C 'work' account it throws no errors, does not ask for permission, returns back to the page without actually being logged in and with nothing on the console.
- If I login with Tenant C 'personal' account it tells me the tenant live.com is not provisioned for the app.
My questions are:
- Why did it even let Tenant B to log into the app? They were definitely not provisioned to be able to access it and on the console the tid is clearly of the second tenant meaning (I think) that the account is NOT a guest on tenant A to be able to login.
- I have no idea why the tenant C throws no error on the Azure side but instead just returns back to the page without actually being logged in.
- Is there any documentation that I'm missing on which tenants can sign up into the app? I have looked at Tenant sign-up and onboarding article but it doesn't really address the issue.
Based on the documentation that I have read, the behaviour of Tenant B and C trying to log into the app makes no sense.
active-directory azure-active-directory multi-tenant activedirectorymembership
For your first question, when the first user consents to permissions (and is able to do so), a service principal for the app is created in their tenant and they are logged in.
– juunas
Nov 13 at 13:05
@juunas so that means that anyone with an account could technically sign up to my app? Is there a piece of documentation that I'm missing on how to limit this behaviour? I obviously only want the app to be used by 'allowed' tenants. The 'provisioning' on the app in AD is set to 'manual' with no other option currently.
– SebastianG
Nov 13 at 13:13
At the moment, no. Your app back-end needs to check tenant ids of users to see they are one of the valid ones. Your front-end can of course check as well, though it cannot replace the back-end checks.
– juunas
Nov 13 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 at 13:14
1
@juunas thank you for the insight -- with this knowledge I can deduce what was an anomaly and what is the desired behaviour. I will continue to look into the behaviour of Tenant C as an error with Tenant C instead of thinking that Tenant B is the anomaly. I'd be happy to mark your answer as the right solution if you post it as an answer! Thanks!
– SebastianG
Nov 13 at 15:28
|
show 4 more comments
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I am trying to build a scalable multi-tenant b2b SAAS in Azure AD using Angular in the front end and node + Azure MS SQL sharded db design.
I've spend a week going through the MS documentation and examples (tailspin, survey apps) and have started testing the multi-tenant behaviour in an angular7 app that has nothing other than authentication with adal-angular4 on it which I've used for ~5 other projects that are currently in production.
So far, I can't for the life of me figure out the reason behind this unpredictable behaviour. I have 3 tenants: A - B - C
A is the developer tenant + my admin account, B is another company's tenant + my normal user account and C is a AD Free tier tenant with my personal account.
I have done nothing else to my app in Azure AD on the developer AD other than switch that multi-tenant setting to on and changing Oauth2implicitflow to true.
If I login with Tenant A into the app, all is good, in the console I
can see tenant A's GUID under TID.If I login with Tenant B - it asks for permissions the first time and then lets me in (why??).
- If I login with Tenant C 'work' account it throws no errors, does not ask for permission, returns back to the page without actually being logged in and with nothing on the console.
- If I login with Tenant C 'personal' account it tells me the tenant live.com is not provisioned for the app.
My questions are:
- Why did it even let Tenant B to log into the app? They were definitely not provisioned to be able to access it and on the console the tid is clearly of the second tenant meaning (I think) that the account is NOT a guest on tenant A to be able to login.
- I have no idea why the tenant C throws no error on the Azure side but instead just returns back to the page without actually being logged in.
- Is there any documentation that I'm missing on which tenants can sign up into the app? I have looked at Tenant sign-up and onboarding article but it doesn't really address the issue.
Based on the documentation that I have read, the behaviour of Tenant B and C trying to log into the app makes no sense.
active-directory azure-active-directory multi-tenant activedirectorymembership
I am trying to build a scalable multi-tenant b2b SAAS in Azure AD using Angular in the front end and node + Azure MS SQL sharded db design.
I've spend a week going through the MS documentation and examples (tailspin, survey apps) and have started testing the multi-tenant behaviour in an angular7 app that has nothing other than authentication with adal-angular4 on it which I've used for ~5 other projects that are currently in production.
So far, I can't for the life of me figure out the reason behind this unpredictable behaviour. I have 3 tenants: A - B - C
A is the developer tenant + my admin account, B is another company's tenant + my normal user account and C is a AD Free tier tenant with my personal account.
I have done nothing else to my app in Azure AD on the developer AD other than switch that multi-tenant setting to on and changing Oauth2implicitflow to true.
If I login with Tenant A into the app, all is good, in the console I
can see tenant A's GUID under TID.If I login with Tenant B - it asks for permissions the first time and then lets me in (why??).
- If I login with Tenant C 'work' account it throws no errors, does not ask for permission, returns back to the page without actually being logged in and with nothing on the console.
- If I login with Tenant C 'personal' account it tells me the tenant live.com is not provisioned for the app.
My questions are:
- Why did it even let Tenant B to log into the app? They were definitely not provisioned to be able to access it and on the console the tid is clearly of the second tenant meaning (I think) that the account is NOT a guest on tenant A to be able to login.
- I have no idea why the tenant C throws no error on the Azure side but instead just returns back to the page without actually being logged in.
- Is there any documentation that I'm missing on which tenants can sign up into the app? I have looked at Tenant sign-up and onboarding article but it doesn't really address the issue.
Based on the documentation that I have read, the behaviour of Tenant B and C trying to log into the app makes no sense.
active-directory azure-active-directory multi-tenant activedirectorymembership
active-directory azure-active-directory multi-tenant activedirectorymembership
asked Nov 13 at 13:02
SebastianG
690114
690114
For your first question, when the first user consents to permissions (and is able to do so), a service principal for the app is created in their tenant and they are logged in.
– juunas
Nov 13 at 13:05
@juunas so that means that anyone with an account could technically sign up to my app? Is there a piece of documentation that I'm missing on how to limit this behaviour? I obviously only want the app to be used by 'allowed' tenants. The 'provisioning' on the app in AD is set to 'manual' with no other option currently.
– SebastianG
Nov 13 at 13:13
At the moment, no. Your app back-end needs to check tenant ids of users to see they are one of the valid ones. Your front-end can of course check as well, though it cannot replace the back-end checks.
– juunas
Nov 13 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 at 13:14
1
@juunas thank you for the insight -- with this knowledge I can deduce what was an anomaly and what is the desired behaviour. I will continue to look into the behaviour of Tenant C as an error with Tenant C instead of thinking that Tenant B is the anomaly. I'd be happy to mark your answer as the right solution if you post it as an answer! Thanks!
– SebastianG
Nov 13 at 15:28
|
show 4 more comments
For your first question, when the first user consents to permissions (and is able to do so), a service principal for the app is created in their tenant and they are logged in.
– juunas
Nov 13 at 13:05
@juunas so that means that anyone with an account could technically sign up to my app? Is there a piece of documentation that I'm missing on how to limit this behaviour? I obviously only want the app to be used by 'allowed' tenants. The 'provisioning' on the app in AD is set to 'manual' with no other option currently.
– SebastianG
Nov 13 at 13:13
At the moment, no. Your app back-end needs to check tenant ids of users to see they are one of the valid ones. Your front-end can of course check as well, though it cannot replace the back-end checks.
– juunas
Nov 13 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 at 13:14
1
@juunas thank you for the insight -- with this knowledge I can deduce what was an anomaly and what is the desired behaviour. I will continue to look into the behaviour of Tenant C as an error with Tenant C instead of thinking that Tenant B is the anomaly. I'd be happy to mark your answer as the right solution if you post it as an answer! Thanks!
– SebastianG
Nov 13 at 15:28
For your first question, when the first user consents to permissions (and is able to do so), a service principal for the app is created in their tenant and they are logged in.
– juunas
Nov 13 at 13:05
For your first question, when the first user consents to permissions (and is able to do so), a service principal for the app is created in their tenant and they are logged in.
– juunas
Nov 13 at 13:05
@juunas so that means that anyone with an account could technically sign up to my app? Is there a piece of documentation that I'm missing on how to limit this behaviour? I obviously only want the app to be used by 'allowed' tenants. The 'provisioning' on the app in AD is set to 'manual' with no other option currently.
– SebastianG
Nov 13 at 13:13
@juunas so that means that anyone with an account could technically sign up to my app? Is there a piece of documentation that I'm missing on how to limit this behaviour? I obviously only want the app to be used by 'allowed' tenants. The 'provisioning' on the app in AD is set to 'manual' with no other option currently.
– SebastianG
Nov 13 at 13:13
At the moment, no. Your app back-end needs to check tenant ids of users to see they are one of the valid ones. Your front-end can of course check as well, though it cannot replace the back-end checks.
– juunas
Nov 13 at 13:14
At the moment, no. Your app back-end needs to check tenant ids of users to see they are one of the valid ones. Your front-end can of course check as well, though it cannot replace the back-end checks.
– juunas
Nov 13 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 at 13:14
1
1
@juunas thank you for the insight -- with this knowledge I can deduce what was an anomaly and what is the desired behaviour. I will continue to look into the behaviour of Tenant C as an error with Tenant C instead of thinking that Tenant B is the anomaly. I'd be happy to mark your answer as the right solution if you post it as an answer! Thanks!
– SebastianG
Nov 13 at 15:28
@juunas thank you for the insight -- with this knowledge I can deduce what was an anomaly and what is the desired behaviour. I will continue to look into the behaviour of Tenant C as an error with Tenant C instead of thinking that Tenant B is the anomaly. I'd be happy to mark your answer as the right solution if you post it as an answer! Thanks!
– SebastianG
Nov 13 at 15:28
|
show 4 more comments
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
Why did it even let Tenant B to log into the app? They were definitely not provisioned to be able to access it and on the console the tid is clearly of the second tenant meaning (I think) that the account is NOT a guest on tenant A to be able to login.
When the first user consents to permissions (and is able to do so), a service principal for the app is created in their tenant and they are logged in.
This is how multi-tenant apps are designed to work.
This means any tenant can login to your app.
Your app back-end needs to check tenant ids of users to see they are one of the valid ones. Your front-end can of course check as well, though it cannot replace the back-end checks.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Why did it even let Tenant B to log into the app? They were definitely not provisioned to be able to access it and on the console the tid is clearly of the second tenant meaning (I think) that the account is NOT a guest on tenant A to be able to login.
When the first user consents to permissions (and is able to do so), a service principal for the app is created in their tenant and they are logged in.
This is how multi-tenant apps are designed to work.
This means any tenant can login to your app.
Your app back-end needs to check tenant ids of users to see they are one of the valid ones. Your front-end can of course check as well, though it cannot replace the back-end checks.
add a comment |
up vote
1
down vote
accepted
Why did it even let Tenant B to log into the app? They were definitely not provisioned to be able to access it and on the console the tid is clearly of the second tenant meaning (I think) that the account is NOT a guest on tenant A to be able to login.
When the first user consents to permissions (and is able to do so), a service principal for the app is created in their tenant and they are logged in.
This is how multi-tenant apps are designed to work.
This means any tenant can login to your app.
Your app back-end needs to check tenant ids of users to see they are one of the valid ones. Your front-end can of course check as well, though it cannot replace the back-end checks.
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Why did it even let Tenant B to log into the app? They were definitely not provisioned to be able to access it and on the console the tid is clearly of the second tenant meaning (I think) that the account is NOT a guest on tenant A to be able to login.
When the first user consents to permissions (and is able to do so), a service principal for the app is created in their tenant and they are logged in.
This is how multi-tenant apps are designed to work.
This means any tenant can login to your app.
Your app back-end needs to check tenant ids of users to see they are one of the valid ones. Your front-end can of course check as well, though it cannot replace the back-end checks.
Why did it even let Tenant B to log into the app? They were definitely not provisioned to be able to access it and on the console the tid is clearly of the second tenant meaning (I think) that the account is NOT a guest on tenant A to be able to login.
When the first user consents to permissions (and is able to do so), a service principal for the app is created in their tenant and they are logged in.
This is how multi-tenant apps are designed to work.
This means any tenant can login to your app.
Your app back-end needs to check tenant ids of users to see they are one of the valid ones. Your front-end can of course check as well, though it cannot replace the back-end checks.
answered Nov 14 at 11:12
juunas
20.6k34474
20.6k34474
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53281616%2fazure-ad-multi-tenant-app-unpredictable-behaviour%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
For your first question, when the first user consents to permissions (and is able to do so), a service principal for the app is created in their tenant and they are logged in.
– juunas
Nov 13 at 13:05
@juunas so that means that anyone with an account could technically sign up to my app? Is there a piece of documentation that I'm missing on how to limit this behaviour? I obviously only want the app to be used by 'allowed' tenants. The 'provisioning' on the app in AD is set to 'manual' with no other option currently.
– SebastianG
Nov 13 at 13:13
At the moment, no. Your app back-end needs to check tenant ids of users to see they are one of the valid ones. Your front-end can of course check as well, though it cannot replace the back-end checks.
– juunas
Nov 13 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 at 13:14
1
@juunas thank you for the insight -- with this knowledge I can deduce what was an anomaly and what is the desired behaviour. I will continue to look into the behaviour of Tenant C as an error with Tenant C instead of thinking that Tenant B is the anomaly. I'd be happy to mark your answer as the right solution if you post it as an answer! Thanks!
– SebastianG
Nov 13 at 15:28