IdentityServer4进行身份验证和授权的正确架构

Question

我正在尝试通过IdentityServer4（IS4）上的身份验证来实现正确的体系结构。 因此，我将拥有一台充当身份提供者的服务器，该服务器具有SDC的oidc和oauth2令牌以及访问令牌以保护Web api。用户配置文件将存储在IS4数据库中。 我有很多应用程序都将引用IS4，但在一个简单的场景中，让我们考虑一个应用程序。

我阅读了几篇关于身份验证和授权之间区别的文章，如果我正确理解的话，将授权信息存储在声明中或IS4中的其他技巧不是一个好主意。它应该只管理用户的身份及其属性，而不管理其他应用程序中的权限。

因此，我的疑问在于权限管理...有关授权。 每个应用程序是否都知道通过ID与IS4表示匹配的所有用户来管理特定权限？这意味着我必须将每个应用程序数据库与IS4数据库同步！ 最好实施用于授权管理的服务，该服务存储无法从声明中检索的规则？

这是问题的一个示例：

• 用户John是“标准用户”。我在索赔中看到了。我可以得到有关他的一般角色的信息。
• 由于John不是“管理员”，因此他无法访问应用程序中的打印和设置菜单。
• 我想动态地将访问打印菜单的权限添加到john，而不是设置菜单。

由于约翰将继续担任“标准用户”的角色，所以我认为我必须在特定应用程序中存储“显示打印菜单”权限的信息。

我对体系结构的看法是否正确，或者是否有更好的方法来实现该方案？

Answer 1

我会在IdentityServer中放入真正全局的声明，例如名称，电子邮件，然后在每个应用程序中放入特定于应用程序的声明。只是为了关注点分离。如果将所有声明放在IdentityServer中，否则将很混乱，最好遵循关注点分离。

您不需要在数据库之间开发一些自定义同步，而是在每个应用程序遇到新用户时在每个应用程序中创建一个本地条目。

使用声明转换很容易做到在每个应用程序的登录过程中添加本地声明，例如以下示例：

public class BonusLevelClaimTransformation : IClaimsTransformation
{
    public Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal)
    {
        if (!principal.HasClaim(c => c.Type == "bonuslevel"))
        {
            //Lookup bonus level.....
            principal.Identities.First().AddClaim(new Claim("bonuslevel", "12345"));
        }
        return Task.FromResult(principal);
    }
}

您应该尝试减少令牌中的声明，因为否则它们可能会变得很大。另外，添加到本地ClaimsPrincipal对象的声明越多，会话cookie就会变得越大。

当会话cookie增长时，ASP.NET Core会将其吐入多个cookie，例如：

您希望使令牌保持较小，并且并非每个声明都必须包含在令牌中才能满足基本的授权和身份验证需求。诸如“ CanPrint”，“ Address”或“ UserWebPage”之类的声明可能不包含在其自身的令牌中。一种可能性是通过询问UserInfo端点（documentation）来根据需要加载不太常用的声明。

您还可以使用GetClaimsFromUserInfoEndpoint选项，以发挥自己的优势。有关更多详细信息，请参见this文章。

登录IdentityServer时，即表示您同意所要求的范围。然后，在接收回ID令牌的客户端应用程序中，它将获取其中一些声明并将其放入会话cookie中。然后，通常会删除ID令牌。然后，各个页面（从UserInfo端点）可以请求其他信息，这些页面除了会话cookie中找到的声明以外，还需要其他数据。例如，可能仅在几个页面上需要“ UserWebPage”，而在另一些页面上则需要“ CanPrint”。或者，您可以在会话期间“以某种方式”下载并缓存它。但是，这取决于您如何执行此操作。您还希望将会话cookie保持较小，因为它包含在每个请求中。

Answer 2

在进行了上述讨论并观看了video之后，结论是：

1. 身份验证可以通过IdentityServer4
解决
2. 对于授权，我们只有一些最佳实践，例如使用特定于应用程序的规则引擎将声明映射到权限。
3. 授权逻辑可以由新应用程序应用：“授权提供程序”（Web api + Web UI），该应用程序具有系统中所有应用程序的授权业务逻辑。

每个人都应根据自己的情况编写自己的授权引擎。