https://yourapp.servicebus.windows.net/foo/bar/baz 就是一个namespace，我们熟悉的URL。Service Bus
通过Namespace 来暴露公共的Endpoint，和管理服务组织架构。
Namespace 由Schema+solution+domain+Nodes组成。
Schema有三种，分别为SB、Http、Https。
SB用于TCP连接，端口开了四个9350-9353。
| 端口 | 描述 |
| 9350 | 客户端无安全的单向连接Service Bus |
| 9351 | 单向安全连接 |
| 9352 | 双向安全连接,约会模式（Rendezvous） |
| 9353 | 直连，Service Bus建立通信后，服务端和客户端直接通信而不通过Service Bus |
HTTP用于80端口连接，在TCP在不允许的情况下，很有用。
Https用于443端口连接，安全的http连接。
Solution是客户要发布的应用程序，它和Service Bus Domain组成Namespace的root节点，
根节点下面有子节点。服务发布者可以向不同的子节点发布不同的Service。
ACS是一个宿主服务，为REST和WCF等服务提供联合认证、认证规则驱动、基于声明的授权。下面看下它的架构：
首先看下Access Control Service 这个灰色框，它由Management Service、Management Portal、
STS、Token Transformation Rule Engine组成。
Management Service：可以通过开放数据协议（OData）编程开放管理ACS。
Management Portal：提供基于web的接口，让ACS管理员通过网站管理ACS的配置。
STS：Security Token Service，这个很重要，提供一组Endpoint来给应用程序或者服务颁发Token。
Token Transformation Rule Engine: 用来处理来自客户端的ACS token和 为访问应用程序或服务生成ACS Token。
接下来看看到底怎么认证的。
用户要访问Application，Application需要ACS Token来认证，然后用户在身份提供者那里输入用户名和密码获取Id Token，
然后客户端用Id Token 从STS那里得到ACS Token，再拿着ACS Token访问Application, 这样Client就与Application建立了信任关系。
Service Bus 通过AC来进行权限控制。AC也是通过Namespace给相应的Serivce Bus Namespace节点授权和认证。
每个Service Bus Namespace 都会有一个隐含的Namespace。
如对于Namespace：yourapp.servicebus.windows.net，
其对应的ACS的Namespace是：yourapp-sb.servicebus.windows.net.
根节点包含一份权限要求（claim），其包含三个操作权限（Send，Listen，Manage)
所有字节点都包含一份要求（claim），可以包含部分或全部三个操作权限。
访问权限要求（claim）+操作权限（Operations）+Namespace，组成一个访问规则（Rule）
多个访问规则组成访问规则组。规则能够向下继承，即子Namespace拥有父节点的所有访问规则。
下面以图来说明。
转载于:https://www.cnblogs.com/ericwen/archive/2012/12/07/NamespaceAndAcs.html
