问题描述
例如，我有 3 个服务:
- 身份验证
- 卖家
- 买家
他们每个人都有自己的数据库、模型、服务......等
身份验证服务了解用户、用户组、角色、权限并创建令牌.
我应该在哪里存储卖家/买家实体?关于身份验证服务，还是关于卖方/买方服务?
卖方/买方服务应如何交互以创建新的卖方/买方实体?
卖方/买方服务应如何检查权限?
卖家和买家实体有一些共同的字段:姓名、密码、电子邮件...，但他们每个人都有自己的附加字段.
卖家和买家相互互动.
这对我最近解决的一个问题来说听起来很熟悉
假设您的服务是基于 HTTP 的，那么我建议您查看 oAuth 2.0
来自 RFC 6749
的简短副本OAuth 通过引入授权层解决了这些问题并将客户端的角色与资源的角色分开所有者.在 OAuth 中，客户端请求访问受控资源由资源所有者并由资源服务器托管，并且是颁发一组与资源不同的凭据所有者.
而不是使用资源所有者的凭据访问受保护的资源，客户端获得一个访问令牌——一个字符串，表示特定范围、生命周期和其他访问属性.访问令牌由授权服务器发布给第三方客户端资源所有者的批准.客户端使用访问令牌访问资源服务器托管的受保护资源.
例如，最终用户(资源所有者)可以授予打印服务(客户端)访问存储在照片中的受保护照片 -共享服务(资源服务器)，不共享她的用户名和打印服务的密码.相反，她验证直接与照片共享服务信任的服务器(授权服务器)，它发出打印服务委托-特定凭据(访问令牌).
它只是将身份验证和授权建模为一个工作流
用户
- 拥有一些数据，因此也称为资源所有者
- 有证书
授权服务器
- 拥有并控制用户身份、凭据和声明
- 控制授予和拒绝访问用户的资源(在这种情况下并非真正需要)
- 将用户凭据交换为 access_token，然后客户端可以使用该凭据访问来自资源提供者的信息
- 可选授予一个 refresh_token，可用于续订过期的 access_token
资源提供者
- 有信息的服务
- 信任授权服务器
- 验证 access_token 是否有效(未过期、签名正确等)
- 验证是否存在所需的声明(用户、角色等)
- 并向提出请求的客户发布信息
客户
- 应用程序(内部或第三方)
- 通过已知的授权服务器对用户进行身份验证
- 获得一个access_token
- 使用 access_token 调用资源提供者获取信息
声明身份
声明身份(在这里更详细地解释了) 不仅仅是一个用户名 &密码，它可以为经过身份验证的用户携带许多声明，例如电子邮件、出生日期等，您可以使用这些声明将任何常见的用户属性传达给您的各种服务.
共享属性
现在，您的最后一个问题是将用户(或身份)链接到每个服务中的实体，该实体代表该服务上下文中的某些独特信息……这可以通过将现有的经过身份验证的身份和 access_token 链接到每个服务中用户的内部表示.
类似于:
- 卖家是用户
- 买家是用户
- 用户拥有(声明，access_token)
- 声明是一个键值对
- 声明可以是(姓名、电子邮件、角色等)
For example, I have 3 services:
- Authentication
- Seller
- Buyer
Each of them got their own databases, models, services... etc
Authentication service knows about users, user-groups, roles, permissions and creates token.
Where should I store sellers/buyers entities? On Authentication service, or on Seller/Buyer services?
How should Seller/Buyer services interact to create new seller/buyer entity?
How should Seller/Buyer services check permissions?
Seller and Buyer entities have some common fields: name, password, email..., but also each of them have their own additional fields.
Seller and Buyer interact with each other.
This sounds familiar to a problem I was solving recently
Assuming your services are HTTP based, then I would recommend you check out oAuth 2.0
A short copy from RFC 6749
It simply models the authentication and authorization into a workflow between
A User
- Owns some data, hence it is also called Resource Owner
- Has credential(s)
Authorization Server
- Owns and Controls the User Identity, Credentials, and Claims
- Controls granting & denying access to User's resources (not really required in this scenario)
- Exchanges a user's credentials for an access_token that a Client can then use to access information from a Resource Provider
- Optionally grants a refresh_token that can be used to renew an expired access_token
Resource Provider(s)
- Service that has information
- Trusts the Authorization Server
- Verify access_token is valid (has not expired, signed correctly, etc.)
- Verify required claims are present (user, roles, etc)
- And Release information to a requesting Client
Client(s)
- An Application (internal or 3rd party)
- Authenticates the user via the known authorization server
- Obtains an access_token
- Uses the access_token to call resource provider(s) to obtain information
Claims Identity
A Claims Identity (explained better in more details here) is not just a username & password, it can carry many claims such as an email, a date of birth, etc. for an authenticated user, and you can use those claims to communicate any common user properties to your various services.
Shared Attributes
Now, your last questions was about linking a user (or an identity) to an entity in each service that represents some unique information in that service's context... this can be achieved by linking an existing authenticated identity and access_token to an internal representation of the user in each service.
Something like:
- A Seller Is a User
- A Buyer Is a User
- A User has (Claims, access_token)
- A Claim is a key value pair
- A Claim can be (name, email, role, ... etc)
这篇关于在微服务架构中组织授权的最佳实践?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！