最近观察到可以在 Azure AD 中创建多个同名的服务主体:
注意:它们有不同的 clientIds 但名称相同。这反过来又会在 Azure SQL 中创建用户时产生问题。那么在 AAD 中允许使用同名 App Id 的原因有哪些?
此外,通过企业应用程序查找和通过应用程序注册查看时,相同的客户端 ID 具有不同的 objectid。
是不是因为企业应用程序是所有托管身份、服务主体等的联合体,与应用程序注册相比,企业应用程序的 objectid 创建是不同的。
最近观察到可以在 Azure AD 中创建多个同名的服务主体:
注意:它们有不同的 clientIds 但名称相同。这反过来又会在 Azure SQL 中创建用户时产生问题。那么在 AAD 中允许使用同名 App Id 的原因有哪些?
此外,通过企业应用程序查找和通过应用程序注册查看时,相同的客户端 ID 具有不同的 objectid。
是不是因为企业应用程序是所有托管身份、服务主体等的联合体,与应用程序注册相比,企业应用程序的 objectid 创建是不同的。
那么为什么在 AAD 中允许使用同名的 App Id 呢?
Azure SQL 中的服务主体和用户是完全不同的东西。我不认为一个是对另一个的参考。他们是这样设计的。
一般来说,当一个字段的值不允许重复时,就意味着它是唯一的。我不熟悉 Azure SQL,但它应该遵循这个原则。
为什么 Azure 允许相同的服务主体名称?这是设计使然。在常见的场景中,我们主要根据它的对象 id 来识别唯一性,它是全局唯一的标识符。请不要将名称作为查找服务主体的唯一条件。
从设计的角度来看,我们真的不应该创建两个同名的服务主体。遗憾的是,Azure 并没有限制这一点。
此外,当通过企业应用程序查找和通过应用程序注册查看时,相同的客户端 ID 具有不同的 objectid。
企业应用程序和关联的应用程序注册是两个不同的对象,因此它们具有不同的对象 ID。
应用程序 id 实际上是应用程序注册的唯一标识符。它也只是显示在企业应用程序中。
可以看到Service Principal属性:</p>
appId String关联应用程序的唯一标识符(其 appId 属性)。
以及应用属性:</p>
appId String Azure AD 分配给应用程序的应用程序的唯一标识符。不可为空。只读。