Recently observed that one can create multiple Service principals with the same name in Azure AD :
Note: They have different clientIds but same name. This in turn creates issues while creating users within Azure SQL.
So any reason why same name App Ids are allowed in AAD?
Also , a same client ID has different objectid when looked up via Enterprise applications and when seen via App registrations.
Is it because Enterprise applications is a union of all managed identities, Service principals etc , the objectid creation for Enterprise applications is different as compared to App registrations.
So any reason why same name App Ids are allowed in AAD?
Service principals and users in Azure SQL are totally different things. I don't think one is referential to the other. They designed it like this.
Generally speaking, when the value of a field is not allowed to repeat, it means that it is unique. I'm not familiar with Azure SQL, but it should follow this principle.
Why does Azure allows same service principal name? It's by design. In common scenarios, we mainly identify uniqueness based on its object id, which is globally unique identifier. Please do not use the name as the only condition for finding the service principal.
From a design point of view, we really should not create two service principals with the same name. It's a pity that Azure does not restrict this.
Also, a same client ID has different objectid when looked up via
Enterprise applications and when seen via App registrations.
An enterprise app and the associated app registration are two different objects, so they have different object ids.
The application id is actually the unique identifier for the app registration. It is just also shown in the enterprise app.
You can see Service Principal properties：
appId String The unique identifier for the associated application (its
appId property).
And the Application Properties：
appId String The unique identifier for the application that is
assigned to an application by Azure AD. Not nullable. Read-only.
Related
We're trying to set up a central platform to assign groups to users coming from several organizations.
Each organization has its own identity provider, which we require supports SAML. Using SAML, we authenticate these users onto our platform in an isolated environment, i.e. users from one org should not be able to see users from another.
We were hoping to use Azure AD for this task and its Administrative Unit feature. Administrative Units proved ineffective though, as they don't allow this segregation. Either a users sees all users/groups in the AD, or none at all.
We also cannot use multiple Azure tenants, since we need to map these users onto AWS SSO, which only supports one tenant.
Are you aware of another identity service which allows SAML federated identity and org isolation?
• You can surely configure federated identity segregation and isolation using SAML with Azure AD by leveraging its various features like User based access control (RBAC or Roles Based Access Control) with authentication and identity separation, security assurances for processes and practices using Security Development Lifecycle, Identity based isolation, zero trust architecture, Azure Active Directory, Data encryption, key vault, and many others. The concept for user-based access control can be illustrated through the diagram below. Also, multi-tenancy in the public cloud improves efficiency by multiplexing resources among disparate customers at low cost; however, this approach introduces the perceived risk associated with resource sharing. Azure addresses this risk by providing a trustworthy foundation for isolated cloud services using a multi-layered approach depicted in figure below: -
• Also, do take into consideration that tenant isolation in Azure AD involves two primary elements: -
a) Preventing data leakage and access across tenants, which means that data belonging to Tenant A can't in any way be obtained by users in Tenant B without explicit authorization by Tenant A.
b) Resource access isolation across tenants, which means that operations performed by Tenant A can't in any way impact access to resources for Tenant B.
Access via Azure AD requires user authentication through a Security Token Service (STS). The authorization system uses information on the user’s existence and enabled state through the Directory Services API and Azure RBAC to determine whether the requested access to the target Azure AD instance is authorized for the user in the session. From the below figure, you can illustrate that Aside from token-based authentication that is tied directly to the user, Azure AD further supports logical isolation in Azure through: -
a) Azure AD instances are discrete containers and there's no relationship between them.
b) Azure AD data is stored in partitions and each partition has a pre-determined set of replicas that are considered the preferred primary replicas. Use of replicas provides high availability of Azure AD services to support identity separation and logical isolation.
c) Access isn't permitted across Azure AD instances unless the Azure AD instance administrator grants it through federation or provisioning of user accounts from other Azure AD instances.
d) Physical access to servers that comprise the Azure AD service and direct access to Azure AD’s back-end systems is restricted to properly authorized Microsoft operational roles using the Just-In-Time (JIT) privileged access management system.
e) Azure AD users have no access to physical assets or locations, and therefore it isn't possible for them to bypass the logical Azure RBAC policy checks.
For more information regarding the above, kindly refer to the documentation link below: -
https://aka.ms/AADDataWhitePaper
https://learn.microsoft.com/en-us/azure/role-based-access-control/overview
We currently have an Azure Active Directory tenant, which replicates via AD Connect our on-premises Windows users. We have an on-premises Exchange Server where accounts are my-company.com.
We have another email domain my-company.io for which there are no users yet.
In the immediate future, we want to create a few mailboxes for my-company.io directly in Exchange Online (not on our Exchange Server). These mailboxes will not be attached to Windows domain users.
Later this year, we want to start migrating our my-company.com Exchange mailboxes to Exchange Online, gradually with a hybrid setup.
In this scenario, what does make more sense?
a) Create second tenant in our Azure account, create there any my-company.io AAD users, then add these users to Exchange Online.
b) Add another domain to our existing tenant, create there any my-company.io AAD users, then add these users to Exchange Online.
Our concern is if activating Exchange Online for my-company.io users in the existing tenant, will interfere in any way our future plan to migrate to Exchange Online for my-company.com users.
Both methods should be feasible. The difference is whether the two accounts exist under the same tenant. If you have a reason to let them exist under the same tenant, you should choose the second option. But if you do not require them to exist under the same tenant, creating a new tenant for my-company.io is recommended, because this will reduce the configuration when migrating to Exchange Online for my-company.com users.
Your concern is not superfluous, but they are not unsolvable. If you choose the second option, then you need to carefully design what your hybrid deployment environment is like. For example, there are two types of users, one is a hybrid deployment user, and the other is a cloud-only user. You can refer to this document to choose the configuration you need.
In short, from the perspective of easy configuration and management of different types of users, the first solution is better, while the second solution does not require you to create new tenants and requires you to pay more attention to configuring hybrid deployments.
I'm using Azure Mobile App service for the first time. I have an existing database which is hosted by Azure. I used this database when creating the App service. I followed this tutorial here which demonstrates how to use existing database. I first created the schema with the same name as the App service and then transferred all tables to that schema. Now I'm trying to access these tables from the Azure portal. I went to Easy Tables tab and created the tables with the same name as in my database and when I click into the table, I don't see any records that are already in the database. The new table that was created, doesn't have the same fields as the tables in my database. They have the following fields : "ID", "CREATEDAT", "UPDATEDAT", "VERSION", "DELETED". The tutorial I followed seemed to have worked for many people. I have the primary keys in my tables with the name "id".
Can anyone give me an idea what the problem might be?
The problem is that you followed a tutorial meant for Azure Mobile Services and applied it to Azure App Service - these are two totally different things. Probably most importantly, your tables are not in the [dbo] schema, which is where Easy Tables expects them to be (unless you configure the app service otherwise). In addition, Mobile Services used double-underscore before the system properties, whereas App Service does not.
If you want to use your existing database, follow the instructions in my App Service Mobile Apps tutorial here: https://shellmonger.com/2016/05/11/30-days-of-zumo-v2-azure-mobile-apps-day-19-asp-net-table-controllers/
I have to use ASP.NET MVC 3 or above and SQL Server 2008. As per Multi-Tenant Data Architecture post, there are 3 ways to implement multi-tenancy
Separate Databases
Shared Database, Separate Schemas
Shared Database, Shared Schema
I have following details:
User should be able to backup and restore their data.
No of tenants : 1000 (approx)
Each tenant might belong to different domain(url).
It must support monitoring and management of tenants.
It must support user authentication and authorization for each tenant
It must support tenant customization(enable disable features set)
No of tables in each tenant: 100 (initial)
I would like to know what your experience says about which approach is more suitable for the project considering Economic and Security? Is there any good real time example(open source project) similar to this? I can use one dedicated server for the project.
Your requirement that users should be able to backup its data, can be achivable more easily with approachs 1 and 2... since it will be a native database task.
If you are in approach 3 (shared-shared), you will need to develop the logic to extract all the rows belonging to a single tenant and export it in a xml file or something like that. Then if you need to allow users to restore that backup file, you need to develop a restore logic.
I think this is the only requirement that could make you move away from #3.
Once you set your database using TenantID columns in your table... you can easily use one database for 1 tenant or a small group of tenants if your client is heavily concerned about security. For instance, you could have one database holding tenants that are not paying (free/demo accounts) and paying customers in another one. This way you are using approach #3, but being able to behave as #1 if you need it.
::: BONUS :::
AUTHENTICATION:
You will need to extend the SQL Membership and Role Providers used in your MVC3 app... so that a user login is valid only in the Tenant it belongs to.
MULTIPLE DOMAINS
Here you can see some approaches using ASP.NET MVC3 Routing:
MVC 3 Subdomain Routing
I would always use (3) Shared Database, Shared Schema.
If you want an example, how about Wordpress, Joomla, or any other popular open source web-based project?
Creating separate schemas or databases on a per-tenant basis will lead to massive management overhead. Not to mention increased complexity of analysing your data, costs, etc.
The only reason you'd go for (1) (or perhaps 2) is if you were to give your actual tenant direct access to some/all of the database. As you're using ASP.NET MVC 3, this isn't a consideration.
I have a question that really feels like I should have an easy answer to, but for one reason or another I haven't been able to totally reason around it.
I'm embarking on development of an ASP.NET MVC3 intranet application, and I'm currently working on designing authentication & authorization. We're forced to use basic authentication in our environment, and we use Active Directory, so the authorization part is generally taken care of. Unfortunately our role/user hierarchy in active directory doesn't mirror what I need for the roles in the application, so I'm going to have to define my own.
I'm using SQL Server, so I was originally thinking of using stored procedures for all DML, and then creating roles and adding users in roles in SQL Server, and then controlling access to the stored procedures via those roles. I was also thinking I could query for those SQL Server database-level users & roles in order to use that as the source of authorization info in the application itself. That originally seemed like a great idea, but it doesn't seem like a popular one (for one, it seems the queries for that are a little long and messy for what they produce). Alternatively, would it be better to have the web app impersonate a user for all queries to the server, and then implement a user/role database with my own schema, and only authorize on the application side?
It originally seemed that authorizing on both the application and database side would be a good thing for security, and using the SQL Server user/role objects means that the user and role data wouldn't need to be stored in two places.
I did see some potentially relevant discussion at Best practice on users/roles on SQL Server for a web application, but I think this is a different question overall.
Thanks!
I recommend creating a sql login that the web application will use to connect to sql server. This way you are not impersonating any specific AD account which may get deleted, disabled in the future and can control the user strickly in SQL Server.
I would then recommend implementing roles based authentication in your application. This will enable you to create users and roles that are custom to your application and then assign users to them. This way if a user tries to access a resource that their role is not allowed it will not do any work. Here is a demo app based on this principle http://www.codeproject.com/KB/web-security/rolesbasedauthentication.aspx.