Azure AD multi-tenant app unpredictable behaviour?
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 asked Nov 13 '18 at 13:02
SebastianGSebastianG
789116
|
show 4 more comments
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 asked Nov 13 '18 at 13:02
SebastianGSebastianG
789116
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 '18 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 '18 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 '18 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 '18 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 '18 at 15:28
|
show 4 more comments
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 asked Nov 13 '18 at 13:02
SebastianGSebastianG
789116
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 '18 at 13:02
SebastianGSebastianG
789116
asked Nov 13 '18 at 13:02
SebastianGSebastianG
789116
asked Nov 13 '18 at 13:02
SebastianGSebastianG
789116
asked Nov 13 '18 at 13:02
SebastianGSebastianG
789116
asked Nov 13 '18 at 13:02
SebastianGSebastianG
789116
789116
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 '18 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 '18 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 '18 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 '18 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 '18 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 '18 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 '18 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 '18 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 '18 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 '18 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 '18 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 '18 at 15:28
|
show 4 more comments
1 Answer
1
active
oldest
votes
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 '18 at 11:12
juunasjuunas
21.5k34780
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
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
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 '18 at 11:12
juunasjuunas
21.5k34780
add a comment |
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 '18 at 11:12
juunasjuunas
21.5k34780
add a comment |
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 '18 at 11:12
juunasjuunas
21.5k34780
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 '18 at 11:12
juunasjuunas
21.5k34780
answered Nov 14 '18 at 11:12
juunasjuunas
21.5k34780
answered Nov 14 '18 at 11:12
juunasjuunas
21.5k34780
answered Nov 14 '18 at 11:12
juunasjuunas
21.5k34780
21.5k34780
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.
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 '18 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 '18 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 '18 at 13:14
Multi-tenant app = any Azure AD tenant can use this app
– juunas
Nov 13 '18 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 '18 at 15:28