使用外部身份提供商联合身份隔离
我们正在尝试建立一个中心平台，以将组分配给来自多个组织的用户。
每个组织都有自己的身份提供商，我们需要支持SAML。使用SAML，我们将这些用户在孤立的环境中对我们的平台进行身份验证，一个组织的用户不应从另一个组织那里看到用户。
我们希望将Azure AD用于此任务及其管理单位功能。但是，行政部门证明是无效的，因为它们不允许这种隔离。用户可以看到广告中的所有用户/组，或者根本没有。
我们也不能使用多个Azure租户，因为我们需要将这些用户映射到仅支持一个租户的AWS SSO上。
您是否知道另一个允许SAML联合身份和组织隔离的身份服务？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
•您可以通过利用其各种功能（例如用户基于RBAC或基于RBAC或基于角色的访问权限控制），使用身份验证和身份分离，使用安全性，使用安全性使用安全性，使用安全保证，使用安全保证使用安全性，可以使用安全性配置SAML和Azure AD配置联合身份隔离和隔离。开发生命周期，基于身份的隔离，零信任体系结构，Azure Active Directory，数据加密，密钥库等。基于用户的访问控制的概念可以通过下图说明。另外，
公共云中的多租户通过以低成本在不同客户中的资源中多重资源来提高效率；但是，这种方法引入了与资源共享相关的感知风险。 Azure通过使用多层方法为孤立的云服务提供值得信赖的基础来解决这种风险： -•也考虑到Azure AD中的租户隔离涉及两个主要元素： -
a）防止租户的数据泄漏和访问，这意味着属于租户的数据A无法以租户B中的用户在没有租户A 明确授权的情况下以任何方式获得。
b）跨租户的资源访问隔离，这意味着租户执行的操作不会以任何方式影响租户B 的资源访问。
通过Azure AD访问需要通过安全令牌服务（STS）验证用户身份验证。授权系统使用有关用户存在的信息，并通过Directory Services API和Azure RBAC启用了状态，以确定是否在会话中为用户授权对目标Azure AD实例的访问。从下图中，您可以说明除了直接与用户绑定的基于令牌的身份验证外，Azure AD进一步支持Azure中的逻辑隔离： -是离散的容器，它们之间没有关系。
b） Azure AD数据存储在分区中，每个分区都有一组预定的副本集，这些副本被认为是首选的主要复制品。使用复制品可提供高度可用的Azure AD服务来支持身份分离和逻辑隔离。
c）不允许在Azure AD实例中访问，除非Azure AD实例管理员通过联合或从其他Azure AD Instances 提供的用户帐户提供授予它。
d）对构成Azure AD服务和直接访问Azure AD的后端系统的服务器的物理访问仅限于使用Just-I-Time（JIT）特权访问管理系统。
e） Azure AD用户无法访问物理资产或位置，因此他们不可能绕过逻辑Azure RBAC策略检查。
有关上述信息的更多信息，请参阅下面的文档链接： -
https：//aka.ms/aaddatawhitepaper < /aaddatawhitepaper
https://learn.microsoft.com/en -us/azure/基于角色的访问控制/概述
• 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 approachdepicted 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