Java客户端对接Hyperledger Composer区块链的认证授权方案问询

既然你已经开启了Composer Rest Server的认证和多用户模式，而且Web应用本身有认证体系，那核心就是把Web应用的用户和Hyperledger Composer的身份、参与者体系绑定起来，具体可以按下面几步来操作：

• 第一步：把Web应用用户映射到Composer参与者
  区块链的权限是基于业务网络里的参与者（Participant）来控制的，所以首先得让Web应用的用户对应上Composer业务网络中的某个参与者实例。
  举个例子，如果你的业务网络定义了User参与者类型：

  participant User identified by userId {
      o String userId
      o String name
  }
  

  用户登录Web应用后，你的后端要先检查该用户的userId对应的User参与者是否已经存在于区块链上。如果不存在，就用Web应用的服务身份（一个拥有创建参与者权限的身份）调用Composer REST API的POST /api/User来创建这个参与者。

• 第二步：为用户发行Composer身份并绑定到参与者
  有了对应的参与者后，你需要为这个用户发行一个专属的Composer身份，并且把这个身份和参与者绑定。这一步还是得靠Web应用的服务身份来执行，调用Composer的系统API：

  POST /api/system/identities/issue
  请求体：
  {
      "participant": "org.example.User#你的Web应用用户ID",
      "userID": "自定义的身份ID（比如和Web应用用户ID一致）",
      "options": {
          "certificate": false
      }
  }
  

  这个请求会返回一个userSecret，你得在后端暂时存下来，别直接传给前端，不安全。

• 第三步：获取Rest Server的访问令牌
  接下来，你的Web应用后端可以用刚才拿到的userID和userSecret，调用Composer Rest Server的令牌接口（比如POST /auth/token，具体取决于你用的认证方式）来获取JWT令牌。请求示例：

  POST /auth/token
  请求体：
  {
      "username": "刚才的userID",
      "password": "对应的userSecret"
  }
  

  拿到令牌后，把这个JWT令牌返回给前端，前端后续调用Composer REST API时，只需要在请求头里带上Authorization: Bearer <你的令牌>，就能以该用户的身份和区块链交互了。

• 第四步：配置业务网络的ACL权限
  最后别忘了在业务网络的permissions.acl文件里配置对应的权限规则，确保绑定后的用户身份能执行对应的操作。比如允许User参与者提交特定交易：

  rule AllowUserToSubmitTransactions {
      description: 允许普通用户提交自己的交易
      participant: "org.example.User"
      operation: CREATE
      resource: "org.example.YourTransaction"
      action: ALLOW
  }
  

  配置完ACL后，要更新并重新部署业务网络，让规则生效。

额外注意点 #

• 服务身份的权限：用来发行身份的服务身份必须拥有IssueIdentity的权限，你可以在ACL里给它开权限：

  rule AllowServiceToIssueIdentities {
      description: 允许服务身份发行用户身份
      participant: "org.hyperledger.composer.system.NetworkAdmin"
      operation: ALLOW
      resource: "org.hyperledger.composer.system.IssueIdentity"
      action: ALLOW
  }
  

• 令牌安全：不要把userSecret暴露给前端，全程由后端处理身份发行和令牌获取，只把JWT令牌传给前端用。另外可以配置JWT的过期时间，定期让令牌失效，提升安全性。

内容的提问来源于stack exchange，提问作者blahblahblah