Bearer token identity webapi - 细粒度安全
Bearer token identity webapi - fine grained security
我们正在开发 AngularJS/SPA 应用程序，例如500 个表单，连接到 ASPNET WebAPI。任何表单都具有 "read"、"write"、"query" 和 "additional custom" 访问权限。访问权限可以在 "roles" 中组合在一起。每个用户都可以定义一个或多个角色 and/or 对特定表单的特定权限。
我研究了使用 OpenId Connect/Oauth2 和基于令牌 authentication/authorization 的新身份安全框架。身份验证作为用户登录到 internal/external IdentityProvider（如果成功，则返回身份令牌）。在访问资源（web API）之前，需要访问令牌。
我也在玩 identityserver V3，它看起来不错。
对于身份验证过程（身份令牌），一切正常。
对于授权过程（访问令牌），我找不到合适的实现细节。
所以这里的问题是：
1.) 安全是使用声明定义的。如果每个用户有很多声明（细粒度安全性，由用户声明定义），用户是否需要在每次调用资源之前向 IdentityProvider 询问访问令牌？
每次访问资源时用户询问 IdentityProvider 的开销如何？
是否允许用户仅发送身份令牌和资源然后向身份管理器请求访问令牌（代表用户）？
此外，为了优化访问框架，IdentityManager 是否可以直接访问 Provider 数据库（而不是生成和验证令牌）。这在技术上意味着 IdentityProvider 和 ResourceProvider 是紧密耦合的。
2.) 如果特权未使用声明定义。只有身份令牌同时也是访问令牌。在应用程序中，有内部 ResourceManager，它存储分配给身份用户的访问权限（基于角色，细粒度）。因此 ResourceManager 以一种从身份令牌识别用户的方式充当过滤器，然后检查数据库的访问权限并决定用户是否可以使用资源。这意味着 ResourceProvider 是应用程序的一部分而 IdentityProvider 仅用于身份验证？这也适用于 "modern" 类型的应用程序安全系统吗？
3.) 混合选项。 IdentityProvider 具有身份和角色声明。 ResourceProvider 将角色和细粒度权限映射到 Identity roles/users。在这种情况下，我不知道外部提供商如何，例如Google/FB 可以知道我们的应用需要什么类型的角色吗？
4.) 使用外部身份提供者时，例如Google，从访问权限的角度来看，哪些声明通常可用于我们的应用程序（个人声明除外，例如姓名、电子邮件、年龄、出生日期等）？ Bee Google admin（角色）不代表它也是我们app的admin吗？
很抱歉post :)
Rgds，
弗兰克
玩过IndentityServer，答案很简单。 IdentityServer 的主要作用是authentication/token代。
对于身份验证，应用程序重定向到 IdentityServer。 IdentityServer returns token (identity, access) to client.该令牌使用 HTML header（不记名令牌）发送到 API。
在 API 方面，OWIN 框架需要用于令牌验证的过滤器。过滤器是使用 "Thinktecture.IdentityServer3.AccessTokenValidation" 实现的。资源管理器使用过滤器来检查访问令牌是否允许使用特定的 API。
如何实现细粒度的安全性是个问题。问题是令牌的大小（令牌是每次调用 WebAPI 的一部分）。
将资源管理器与应用程序混合使用是不对的。但是对于细粒度的安全性，我相信这是我们唯一的选择。
此外，外部提供商只能 return 可用的用户声明（google、facebook 等）。页面上的文档中非常精确地解释了外部机制如何工作的详细描述
leastprivilege
您不需要使用声明来获得细粒度的安全性。身份服务器的主要目的是进行身份验证和生成令牌，以便客户端可以向其他服务证明其身份。用它来验证，而不是授权。
在您的 Web API 服务中，您可以拥有自己的具有用户、角色和权限的授权数据库，这样这些信息就不会通过声明来表示，而是存储在这个数据库中。通过这种方式，所有关于授权的知识都可以由您的应用程序处理。
最后一步是将通过外部身份验证服务进行身份验证的每个用户映射到您的 Web API 授权数据库中的用户。
您还记得您是如何登录 Stack Overflow 的吗？我这样做了，而且我已经将两个不同的 Google 帐户映射到我的 SO 用户帐户。我可以使用其中任何一个 Google 帐户登录到 SO。因此，SO 不负责检查我是谁（身份验证），但是一旦它从外部服务接收到令牌，它就会确定我是谁，并且可以决定我可以做什么（授权）。
这是最灵活的工作方式，不会产生大量索赔。这不是索赔的目的。我记得有人将索赔与驾驶执照进行比较：它们非常相似，因为它是由第三方创建的，可以提供有关一个人的信息。在现实生活中租车不需要检查这个人是否会开车，因为他们可以向他索要他的驾驶执照（这就像一个索赔）但是，除了拥有这些信息之外，他们还可以根据自己的标准（如应用程序授权）决定租车或不租车。
将外部身份验证映射到应用程序用户的一个优点是您可以轻松更改身份验证提供程序或使用不同的身份验证提供程序。也许你也可以在声明中使用一些信息，比如电子邮件帐户，但你不依赖于授权声明。
我们正在开发 AngularJS/SPA 应用程序，例如500 个表单，连接到 ASPNET WebAPI。任何表单都具有 "read"、"write"、"query" 和 "additional custom" 访问权限。访问权限可以在 "roles" 中组合在一起。每个用户都可以定义一个或多个角色 and/or 对特定表单的特定权限。
我研究了使用 OpenId Connect/Oauth2 和基于令牌 authentication/authorization 的新身份安全框架。身份验证作为用户登录到 internal/external IdentityProvider（如果成功，则返回身份令牌）。在访问资源（web API）之前，需要访问令牌。 我也在玩 identityserver V3，它看起来不错。 对于身份验证过程（身份令牌），一切正常。 对于授权过程（访问令牌），我找不到合适的实现细节。
所以这里的问题是： 1.) 安全是使用声明定义的。如果每个用户有很多声明（细粒度安全性，由用户声明定义），用户是否需要在每次调用资源之前向 IdentityProvider 询问访问令牌？ 每次访问资源时用户询问 IdentityProvider 的开销如何？ 是否允许用户仅发送身份令牌和资源然后向身份管理器请求访问令牌（代表用户）？ 此外，为了优化访问框架，IdentityManager 是否可以直接访问 Provider 数据库（而不是生成和验证令牌）。这在技术上意味着 IdentityProvider 和 ResourceProvider 是紧密耦合的。
2.) 如果特权未使用声明定义。只有身份令牌同时也是访问令牌。在应用程序中，有内部 ResourceManager，它存储分配给身份用户的访问权限（基于角色，细粒度）。因此 ResourceManager 以一种从身份令牌识别用户的方式充当过滤器，然后检查数据库的访问权限并决定用户是否可以使用资源。这意味着 ResourceProvider 是应用程序的一部分而 IdentityProvider 仅用于身份验证？这也适用于 "modern" 类型的应用程序安全系统吗？
3.) 混合选项。 IdentityProvider 具有身份和角色声明。 ResourceProvider 将角色和细粒度权限映射到 Identity roles/users。在这种情况下，我不知道外部提供商如何，例如Google/FB 可以知道我们的应用需要什么类型的角色吗？
4.) 使用外部身份提供者时，例如Google，从访问权限的角度来看，哪些声明通常可用于我们的应用程序（个人声明除外，例如姓名、电子邮件、年龄、出生日期等）？ Bee Google admin（角色）不代表它也是我们app的admin吗？
很抱歉post :) Rgds， 弗兰克
玩过IndentityServer，答案很简单。 IdentityServer 的主要作用是authentication/token代。 对于身份验证，应用程序重定向到 IdentityServer。 IdentityServer returns token (identity, access) to client.该令牌使用 HTML header（不记名令牌）发送到 API。 在 API 方面，OWIN 框架需要用于令牌验证的过滤器。过滤器是使用 "Thinktecture.IdentityServer3.AccessTokenValidation" 实现的。资源管理器使用过滤器来检查访问令牌是否允许使用特定的 API。
如何实现细粒度的安全性是个问题。问题是令牌的大小（令牌是每次调用 WebAPI 的一部分）。 将资源管理器与应用程序混合使用是不对的。但是对于细粒度的安全性，我相信这是我们唯一的选择。
此外，外部提供商只能 return 可用的用户声明（google、facebook 等）。页面上的文档中非常精确地解释了外部机制如何工作的详细描述 leastprivilege
您不需要使用声明来获得细粒度的安全性。身份服务器的主要目的是进行身份验证和生成令牌，以便客户端可以向其他服务证明其身份。用它来验证，而不是授权。
在您的 Web API 服务中，您可以拥有自己的具有用户、角色和权限的授权数据库，这样这些信息就不会通过声明来表示，而是存储在这个数据库中。通过这种方式，所有关于授权的知识都可以由您的应用程序处理。
最后一步是将通过外部身份验证服务进行身份验证的每个用户映射到您的 Web API 授权数据库中的用户。
您还记得您是如何登录 Stack Overflow 的吗？我这样做了，而且我已经将两个不同的 Google 帐户映射到我的 SO 用户帐户。我可以使用其中任何一个 Google 帐户登录到 SO。因此，SO 不负责检查我是谁（身份验证），但是一旦它从外部服务接收到令牌，它就会确定我是谁，并且可以决定我可以做什么（授权）。
这是最灵活的工作方式，不会产生大量索赔。这不是索赔的目的。我记得有人将索赔与驾驶执照进行比较：它们非常相似，因为它是由第三方创建的，可以提供有关一个人的信息。在现实生活中租车不需要检查这个人是否会开车，因为他们可以向他索要他的驾驶执照（这就像一个索赔）但是，除了拥有这些信息之外，他们还可以根据自己的标准（如应用程序授权）决定租车或不租车。
将外部身份验证映射到应用程序用户的一个优点是您可以轻松更改身份验证提供程序或使用不同的身份验证提供程序。也许你也可以在声明中使用一些信息，比如电子邮件帐户，但你不依赖于授权声明。