Hyperledger Composer中ACL作用域疑问：仅在Composer层生效还是延伸至Fabric层？
Great question — this is a common point of confusion when working with Composer on top of Fabric. Let's break it down plainly:
Core Answer
Hyperledger Composer's ACL rules only enforce access control when you interact with the ledger through Composer's layers — they do NOT extend to direct interactions with the Hyperledger Fabric底层.
Why This Is The Case
Let's break down the two separate permission systems:
- Composer ACLs: These are part of Composer's business logic layer. When you use Composer's tools (REST server, CLI, or client SDK) to query or update assets/transactions, Composer's runtime checks the ACL rules you defined before passing the request to the underlying Fabric chaincode. This is purely an upper-layer guardrail for Composer-specific workflows.
- Fabric底层权限: Fabric has its own independent access control mechanisms:
- Channel policies that govern who can perform channel-level actions (like joining peers, adding organizations)
- Endorsement policies that define which peers must approve a transaction
- MSP (Membership Service Provider) rules that manage identity validation and organization membership
Example Scenario
Suppose you define a Composer ACL that restricts "only users with the admin role can modify the Vehicle asset". If someone bypasses Composer entirely — say, using the Fabric CLI to directly invoke the underlying chaincode function that modifies Vehicle assets — the Composer ACL won't stop them. As long as that user passes Fabric's own permission checks (e.g., their identity is valid for the channel, they meet the chaincode's endorsement policy), the transaction will succeed.
Key Takeaway
Composer ACLs add a business-focused access control layer for applications built with Composer, but they don't replace or extend Fabric's native security controls. If you need to secure direct Fabric interactions, you have to configure Fabric's own policies and MSP settings separately.
内容的提问来源于stack exchange，提问作者user9040429
