RVP：存在和即时消息传送协议 (4)

2000年12月09日 02:33:00

访问权限

• 受支持的元素定义权限有 read、write、readacl、writeacl 和 all。
  
  
• 不支持的访问权限有 writeowner、delete、createchild 和 deletechild。
  
  
• 拥有 allow 或 deny 父级的新访问权限元素在下面指定。

名称	作用	值
send-to	确定允许谁将 NOTIFY 消息发送到给定的节点	None
presence	确定允许谁访问 presence 信息	None
list	确定允许谁列出属性	None
receive-from	确定允许谁接收通知和订阅通知	None
subscriptions	确定允许谁访问订阅列表	None
subscribe-others	确定允许谁使用不识别的回调来订阅属性和通知	None

委托人

所有的 RVP PRINCIPALS 都具有一个唯一的标识符，就是它们的逻辑 URL。为了在 ACL 内标识此 PRINCIPAL，每个 >principal<>/principal< 标记对都必须包含一个且只能包含一个 >rvp-principal< 子级和 >credentials< 子级。

名称	定义	父级	作用	值
rvp-principal		>principal<	封装一个 RVP URL，并使它与任何其它 PRINCIPAL 表示保持不同，而不管该表示是什么。	任何有效的 RVP PRINCIPAL 标识符（像 http://im.acme.com/instmsg/maxb 那样的 PRINCIPAL 标识符或像 im.acme.com 那样的 PRESENCE SERVICE 标识符）。不允许 Null 值。PRESENCE SERVICE 会去除 RVP PRINCIPAL 标识符周围的空白。PRESENCE SERVICE 永远不会在 >rvp-principal< 中生成空白。注意到没有任何形式的 PRINCIPAL 继承（即 im.example.com 不是 http://im.example.com/instmsg/maxb 的超集）是很重要的。 如果一个 PRINCIPAL 使用不是在 >credentials/< 中作为可接受的凭据（作为 >any/< 元素的一部分）显式或隐式列出的凭据进行连接，则应该这样看待 PRINCIPAL，就好像 PRINCIPAL 根本没有在 ACL 中列出一样。如果没有指定凭据，或者如果 >credentials/< 为空，则必须用 400—Credentials Not Specified 拒绝 ACL 操纵。
Credentials	>!Element credentials (any | (ntlm?, digest?, assertion?, internal?))<	>principal<	唯一地标识 PRINCIPAL 必须给出的凭据。	由一个或多个有效凭据标识符组成的任何集合（当前为 ">ntlm< >digest< >assertion< >internal<" 或 ">any<" 的任意组合）。
Ntlm	>!Element ntlm EMPTY)	>credentials<	表明 PRINCIPAL 必须满足一个来自 PRESENCE SERVICE 的 NTLM 挑战。在设置 ACL 后，PRESENCE SERVICE 就不应该检查指定 PRINCIPAL 的存在。	None
Digest	>!Element digest EMPTY)	>credentials<	表明 PRINCIPAL 必须满足一个来自 PRESENCE SERVICE 的 digest 挑战。在设置 ACL 后，PRESENCE SERVICE 就不应该检查指定 PRINCIPAL 的存在。	None
Assertion	>!Element assertion EMPTY)	>credentials<	表明 PRINCIPAL 不需要给出凭据来证明其身份。	None
Internal	>!Element internal EMPTY)	>credentials<	表明 PRINCIPAL 必须通过依赖 PRESENCE SERVICE 的某种带外机制（另一个过程，如电子邮件、电话等）来证明其身份。	None
Any	>!Element any EMPTY)	>credentials<	表明给出任何有效凭据的 PRINCIPAL 应该被认为是此 PRINCIPAL。	None

注： AllAuthPrincipals，一个代表提供某种形式身份验证的所有 PRINCIPAL 的一般集合 PRINCIPAL，对于 >credentials< 标识符是多余的，且得不到支持。

示例

当一个 PRESENTITY 启动时，它需要获取当前 PRINCIPAL 的 ACL。以下示例说明所有的 WATCHERS（http://im.example.com/instmsg/aliases/maxb 除外）是如何被允许得到 PRINCIPAL 存在的通知并发送通知的。它还说明 http://im.acme.com/instmsg/aliases/maxb 所知晓的 PRINCIPAL 被授予了其自身节点的所有权限。

          <
   
   <请求 acl instmsg aliases maxb http 1.1 rvp-notifications-version: 0.2 host: im.acme.com content-length: 0 rvp-from-principal: http: << 响应 200 successful content-type: text xml xxxx>
    
    ?xml version="1.0"?<           >a:rvpacl xmlns:a="http://schemas.microsoft.com/rvp/acl/"<                >a:acl<                        >a:inheritance
    
    
     
     /a:inheritance<                        >a:ace<                                >a:principal<                                        >a:rvp-principal<                                       http://im.example.com/instmsg/aliases/maxb/                                        >/a:rvp-principal<                                        >a:credentials<                                                >a:assertion/<                                                >a:digest/<                                                >a:ntlm/<                                        >/a:credentials<                                >/a:principal<                                >a:grant/<                                >a:deny<                                        >a:send-to/<                                        >a:presence/<                                >/a:deny<                        >/a:ace<                        >a:ace<                                >a:principal<                                        >a:allprincipals/<                                        >a:credentials<                                                >a:assertion/<                                                >a:digest/<                                                >a:ntlm/<                                        >/a:credentials<                                >/a:principal<                                >a:grant<                                        >a:list/<                                        >a:read/<                                        >a:send-to/<                                        >a:presence/<                                >/a:grant<                                >a:deny/<                        >/a:ace<                        >a:ace<                                >a:principal<                                        >a:rvp-principal<                                                http://im.acme.com/instmsg/aliases/maxb                                        >/a:rvp-principal<                                        >a:credentials<                                                >a:assertion/<                                        >/a:credentials<                                >/a:principal<                                >a:grant<                                        >a:list/<                                        >a:read/<                                        >a:write/<                                        >a:send-to/<                                        >a:receive-from/<                                        >a:readacl/<                                        >a:writeacl/<                                        >a:presence/<                                        >a:subscriptions/<                                        >a:subscribe-others/<                                >/a:grant<                                >a:deny/<                        >/a:ace<                >/a:acl<           >/a:rvpacl<            
    
    
   
   

其它方法

不支持 GET、HEAD、POST 和 PUT 这些 HTTP 方法。如果接收到这些方法，应该返回 501—Not Implemented（没有实施）。

也不支持 COPY、MOVE、LOCK、UNLOCK 和 OPTIONS 这些 DAV 方法。COPY 和 MOVE 应该返回错误代码 405—Method not allowed（不允许该方法）。如果接收到 LOCK、UNLOCK 和 OPTIONS，则应该返回错误代码 501—Not Implemented。

---

身份验证

身份验证是通过使用 HTTP/1.1 方法在 RVP 内完成的。这使得 PRESENCE SERVICE 通过返回一个状态代码 401—Unauthorized （未经授权），以及至少一个指定允许授权的架构的 WWW-Authenticate 标头，来拒绝对保护资源的访问。在 RVP 内，允许两种架构：NTLM (NT Lan Manager) 和 Digest Access 身份验证。

RVP 使用 HTTP 挑战-响应身份验证，这种身份验证允许 PRESENCE SERVICE 为 PRESENTITY 提供允许的身份验证类型。然后期望 PRESENTITY 根据返回的身份验证信息重试。

NT Lan Manager (NTLM)

由于用户名和口令不以明文（未加密）的形式在网络中移动，所以由 Exchange 2000 Server 提供的 NT Lan Manager 身份验证允许用一种安全的方法对 PRESENTITY 进行身份验证。

Digest Access 身份验证

Digest Access 身份验证验证双方是否共享一个秘密（即口令），此秘密不以明文的形式传递。有关 Digest Access 身份验证的详细信息，请参阅 RFC 2617-TTP Authentication: Basic and Digest Access Authentication。不支持 NTLM 的平台（如 UNIX）上的客户机可以使用此身份验证架构。

示例

以下示例说明允许 PRESENTITY 对其自身节点上的订阅进行身份验证的请求和响应。正如 SUBSCRIBE 请求示例中所示，PRINCIPAL 被称为 http://im.acme.com/instmsg/aliases/maxb。此示例说明服务器拒绝初始请求并指定可用的身份验证方案是 NTLM 和 Digest。然后，客户机使用 NTLM 身份验证发出第二个请求。

          << 请求                      SUBSCRIBE /instmsg/aliases/maxb HTTP/1.1           Subscription-Lifetime: 14400           Notification-Type: pragma/notify           Call-Back: http://198.176.154.132:1234           RVP-Notifications-Version: 0.2          Host: imhome1.acme.com           Content-Length: 0           RVP-From-Principal: http://im.acme.com/instmsg/aliases/maxb                      << 响应                      HTTP/1.1 401 Access Denied           WWW-Authenticate: Negotiate           WWW-Authenticate: NTLM           WWW-Authenticate: Digest qop="auth", realm="im.acme.com",           nonce="78a8ffeeb123458a400358100000b4d0ed33ae239123441b44896487feda"           Content-Type: text/html           Content-Length: XXXX           RVP-Notifications-Version: 0.2                      << 请求                      SUBSCRIBE /instmsg/aliases/maxb HTTP/1.1           Subscription-Lifetime: 14400           Notification-Type: pragma/notify           Call-Back: http://198.176.154.132:1234           RVP-Notifications-Version: 0.2           Host: imhome1.acme.com           Content-Length: 0            Authorization: NTLM           TlRMTVNTUAADABCDGAAYAF4AAAAYABgAdgAAAAAAAABABCDDgAOAEAAAAAQABAATg          AAAAAAAACOAAAABYKAgHIAbwBiAGUAcgB0AG8AUgBPAEIARQBS                      << 响应                    HTTP/1.1 200 Successful           Subscription-Id: 98210           Subscription-Lifetime: 14400           RVP-Notifications-Version: 0.2    

---

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=3227