IdentityServer4:数据库中不同表中的不同用户类型 [英] IdentityServer4: different user types in different tables in database

问题描述

当前情况:我有一个包含3个WebAPI项目的应用程序(假设API A，B，C).每个都有基于令牌的身份验证(基于OAuthAuthorizationServerProvider).有3种用户类型(假设类型1、2、3).每种用户类型都存储在单独的数据库表中；

Current situation: I have an application with 3 WebAPI projects (let's say API A, B, C). Each has token-based auth (based on OAuthAuthorizationServerProvider). There are 3 user types (let's say Type 1, 2, 3). Each user type is stored in the separate database table;

• 移动客户端(类型1"用户)使用的"API A"
• "API B"部分由移动客户端(类型1"用户)使用，部分由Web客户端(角度应用程序，类型2"用户)使用
Web客户端(类型3"用户)使用的
• "API C"

• "API A" used by mobile clients ("Type 1" users)
• "API B" used partly by mobile clients ("Type 1" users), partly by web client (angular application, "Type 2" users)
• "API C" used by web client ("Type 3" users)

也是

• 类型1"用户可以从"API A"获取令牌并将其从"API B"交换为另一个令牌，以便获得对"API B"资源的访问权限("Type B"使用的"API B"中的某些控制器1"用户，其他-"2类"用户)
• 类型2"用户具有两步授权
  • 他们使用登录名和密码来获得对单个控制器具有受限访问"权限的令牌，以便从中选择一些值
  • 使用先前的令牌和选择的值，他们将其交换为完全访问权限"令牌
  • "Type 1" users can get token from "API A" and exchange it to another token from "API B" in order to get access to "API B" resources (some controllers in "API B" used by "Type 1" users, others - by "Type 2" users)
  • "Type 2" users have 2-step authorization
    • They use login and password to get a token with "restricted access" to a single controller in order to choose some value from it
    • Using the previous token and chosen value they exchange it to "full access" token

    我打算从当前的授权方案迁移到IdentityServer4.所以，我有几个问题:

    I'm planning to migrate from the current authorization scheme to IdentityServer4. So, I have a few questions:

    主要问题:

    1. 如何通过具有单个IdentityServer4实例的单个端点(服务器/连接/令牌)对3个不同数据库表中的3个不同用户类型进行身份验证?

    其他问题:

    1. 如何为类型2"用户实施两步授权?
    2. 在我的情况下，您能提供什么建议?

    谢谢！

    推荐答案

    对于IdentityServer，只有一种类型的用户需要进行身份验证.因此，所有用户都应移至同一张表(如何迁移是另一个问题).如果将用户移动到一个表是一个问题，则IdentityServer可能不是实现安全性的正确工具.尽管可以通过实现自定义用户存储来维护单独的表.可以为每个用户启用两因素身份验证.您可以使用扩展授权来实现自定义授权.

    For IdentityServer there is only one type of user that needs to be authenticated. So all users should be moved to the same table (how to migrate is another question). If moving the users to one table is an issue, then IdentityServer may not be the right tool to implement security. Though it is possible to maintain seperate tables by implementing a custom user store. Two factor authentication can be enabled per user. You can use extension grants to implement custom grants.

    安全性的全部目的是保护您的资源:api.在IdentityServer中，资源名称是该功能的逻辑名称，该功能可以分为多个范围，其中范围是特定功能.

    The whole purpose of security is to protect your resources: the api's. In IdentityServer the resource name is a logical name for the functionality that can be split in several scopes, where a scope is a certain functionality.

    Api1可以是具有多个范围(例如Api1.Read和Api1.Write)的资源，也可以只是Api1.但是Api1，Api2和Api3也可以是Api资源的一部分，其中Api1，Api2和Api3实际上是作用域.在您的情况下，Api1可能是资源，而Api1是 scope .

    Api1 can be the resource with multiple scopes (e.g. Api1.Read and Api1.Write) or simply Api1. But Api1, Api2 and Api3 can also be part of the Api resource where Api1, Api2 and Api3 are in fact scopes. In your case Api1 could be the resource with Api1 as scope.

    要使用户能够访问资源，您需要一个客户端应用程序，尽管您可以有许多可以访问同一资源的客户端.为了支持不同类型的客户端，可以选择多种授权类型.

    To make it possible for the user to access a resource you'll need a client application, though you can have many clients that can access the same resource. In order to support the different types of clients, there are multiple grant types that can be chosen from.

    IdentityServer允许您配置完整图片.

    IdentityServer allows you to configure the complete picture.

    让我们假设有一个客户端可以访问不同的Api，其中每个Api是一个资源/作用域.

    Let's assume there is one client that has access to the different Api's, where each Api is a resource/scope.

    需要允许客户端代表用户访问Api的 ，因为没有用户，客户端无法访问资源.

    The client needs to be allowed to access the Api's on behalf of the user, because the client can't access the resource without user.

    因此，应允许客户端使用某些范围，而该范围需要由客户端请求.没有这个，客户端将无法访问资源.假设为客户端配置了Api1和Api2，但是客户端仅请求Api1.然后Api2和Api3无法访问.

    So the client should be allowed to use certain scopes, where the scope needs to be requested by the client. Without this, a client can't access a resource. Suppose the client is configured for Api1 and Api2, but only Api1 is requested by the client. Then Api2 and Api3 are not reachable.

    这是最高级别授权的一部分.现在是时候让用户参与了.当客户端访问api时，api会知道哪个用户发出了请求(因为sub是访问令牌的一部分).但这还不足以授予或拒绝访问.

    This is all part of the authorization at top level. Now it's time to involve the user. When the client accesses the api then the api knows which user made the request (as sub is part of the access token). But that is not enough to grant or deny access.

    因此，您将需要一些授权用户.关于如何实现这一点，有很多选择.看看文档.

    So you'll need something to authorize the user. There are many options on how to implement this. Take a look at the documentation.

    考虑一个简单的实现，其中有三个策略.并且每个策略都确保只有匹配类型的用户才能访问.

    Consider a simple implementation where there are three policies. And each policy makes sure that only the matching type of user has access.

    那么实际的问题是，如何区分用户类型?

    Then the actual question is, how to distinguish the type of user?

    您可以在 UserClaims 表中添加声明.假设 ClaimType 是UserType，而 value 是1.在资源中添加一个策略，以检查索赔UserType和所需的值.

    You can add a claim in the UserClaims table. Let's assume ClaimType is UserType and value is 1. In the resource add a policy that checks for the claim UserType and the required value.

    为了让IdentityServer将声明添加到访问令牌中，请确保ClaimType是范围的一部分(或在配置了多个范围并且需要ClaimType时为ApiResource).

    In order to let IdentityServer add the claim to the access token, make sure the claimType is part of the scope (or ApiResource when multiple scopes are configured and need the claimType).

    通过将ClaimType UserType添加到Api_范围，意味着在访问该范围时，必须包括该声明. IdentityServer尝试通过仅过滤请求的声明来限制访问令牌中的声明数量.

    By adding the claimType UserType to the Api_ scope, means that when accessing the scope, the claim must be included. IdentityServer tries to limit the number of claims in the access token by filtering on requested claims only.

    当用户访问Api_时，声明应该是访问令牌的一部分(假设为每个用户设置了声明，否则用户完全没有访问权限).您可以对其他api(作用域)重复此设置.

    When the user accesses the Api_, then the claim should be part of the access token (assuming the claim is set for each user, otherwise the user has no access at all). You can repeat this setup for the other api's (scopes).

    在这种情况下，我认为这是可以接受的解决方案.其他选项是较低级别的授权(基于资源)或外包的授权，例如 PolicyServer .

    In this case, I think this is an acceptable solution. Other options are authorization at a lower level (resource based) or outsourced, like PolicyServer.

    请注意，由于SSO，用户也有可能被其他客户端验证.但是，由于仅将访问权限授予某些类型的用户(作为策略的一部分)，因此您可以阻止其他类型的用户访问不适合他们的资源.您可以通过禁用自动登录来防止此行为.

    Please note that because of SSO it may be possible that the user is authenticated by other clients as well. But since access is granted to certain types of users only (as part of the policies), you can prevent other types of users to access the resources that are not meant for them. You can prevent this behaviour by disabling automatic login.

    这篇关于IdentityServer4:数据库中不同表中的不同用户类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！