TOC

  1. Intro
  2. TagModel
  3. Structure
  4. TimeZones
  5. Units
  6. Grids
  7. Filters
  8. Zinc
  9. Json
  10. Trio
  11. Csv
  12. Rest
  13. Ops
  14. Auth
    1. 概述
    2. HTTP 验证
      1. 介绍
      2. HTTP1/1. 认证
        1. 语法限制
      3. 认证协议
        1. Hello
        2. 验证交换
        3. 授权令牌
      4. 认证机制
      5. SCRAM
        1. Hello
        2. 验证交换
      6. References
  15. VFDs
  16. Networks
  17. Energy
  18. Zones
  19. AHUs
  20. VAVs
  21. UnitaryEquips
  22. Chillers
  23. Boilers
  24. Tanks
  25. ElecPanels
  26. Lighting
  27. Builds
  28. Bacnet
  29. ChangeLog
  30. License
Ops VFDs

Authentication

概述

本节介绍了Haystack认证的各个方面。

HTTP 验证

HTTP身份验证定义了通用目的,可插拔的身份验证协议,可由IoT客户端使用身份验证协议,使其与合规的服务器进行身份验证。成功验证后,客户端从服务器接收可用于访问受保护资源的验证令牌。

介绍

获取验证令牌的高级步骤是:

  1. 你好握手
    1. 客户端向服务器发送一个hello消息,标识要验证的用户。
    2. T服务器响应指示该用户支持哪些身份验证机制。
  2. 验证交换
    1. 客户端选择认证机制,并与服务器交换消息进行认证。
    2. 如果服务器认证用户,则向客户端发送可用于访问受保护资源的验证令牌。
    3. 客户端将使用auth令牌,以便将来对服务器的所有请求。

本文档的其余部分更详细地描述了该过程。我们还定义了一套标准认证机制,并定义了认证交换如何在每个机制中工作。

HTTP1/1. 认证

本规范基于"HTTP / 1.1:认证" RFC7235中提供的认证框架。我们建立在这个框架上,通过添加一个明确的方法来建立支持的认证机制是为特定的用户。对于符合客户端和服务器必须遵守的规范,还有一些限制。

语法限制

为了使客户端和服务器尽可能容易地解析认证头,我们对用于编码认证头的语法规则放置以下限制。

以下修改后的语法规则必须用于构建验证头:

auth-scheme = token
auth-param  = token BWS "=" BWS token

challenge   = auth-scheme [ 1*SP #auth-param ]
credentials = auth-scheme [ 1*SP #auth-param ]

从根本上说,我们只允许任何生产规则中的"token"语法。如果原始AUTH-PARAM值不是一个有效的标记,则该值应为使用编码'base64url'与 没有填充 RFC4648

认证协议

身份验证协议是向服务器发送的一系列HTTP请求。用于认证的URI由服务器确定。如果客户端尝试访问没有有效的认证令牌的受保护资源,则服务器应返回401询问。

到服务器的所有消息必须使用HTTP GET方法。

服务器可能在其对客户端的响应中包括"handshakeToken"参数。handshakeToken由服务器用来维护请求之间的状态。如果服务器包含此参数,则客户端必须将其包含在下一个服务器请求中。其值是不透明和服务器定义的。

Hello

认证协议的第一步是让客户端发起一个hello消息的认证握手。授权头用于使用HELLO身份验证方案提供客户端的用户名。username参数是UTF8编码的用户名的base64url编码。

服务器通过401(未经授权)的响应响应您的hello请求。响应使用WWW-Authenticate标头向客户端指示提供的用户名支持哪些认证机制。如果支持多种身份验证机制,服务器应该按照最优先的顺序指定它们。

如果服务器无法识别用户名,则应该至少返回一个具有至少一个有效身份验证机制的401(未经授权)。在验证交换期间,用户将不会验证,此时应发送403(禁止)状态代码。这种方法使得潜在的攻击者更难以确定系统的有效用户名。

在此示例中,用户名为"user",服务器响应指示用户可以使用SCRAM进行身份验证,响应中包含"handshakeToken",因此客户端必须将其包含在其下一个请求中。

C: GET /haystack/about HTTP/1.1
   Host: server.example.com
   Authorization: HELLO username=dXNlcg

S: HTTP/1.1 401 Unauthorized
   WWW-Authenticate: SCRAM hash=SHA-256, handshakeToken=aabbbcc

验证交换

此时,客户端可以选择要用于身份验证的身份验证机制。握手的其余部分是根据这个选择定义的。认证机制必须在本文档中定义为符合本规范。

在认证交换期间,如果客户端无法验证,则服务器必须使用403(禁止)状态代码进行响应。

有关支持的机制[Authentication Mechanisms]`#authMechs`的详细信息,请参阅身份验证机制部分。

授权令牌

一旦服务器验证了客户端,它发送给客户端的最后一个消息必须是200(Ok)。响应必须使用Authentication-Info RFC7615头返回客户端用于将来对受保护资源的请求的"authToken",该参数必须命名'authToken',其值为服务器定义且不透明,只要该规范有关。

服务器也可以返回标题中的其他参数。例如,用于SCRAM认证的最后一个服务器消息包含客户端可以用来验证服务器的信息。

// Authentication Hello
// Authentication Exchange...
S: HTTP/1.1 200 Ok
   Authentication-Info: authToken=xxyyzz

客户端现在已通过服务器进行身份验证,并可能访问受保护的资源。所有对受保护资源的请求必须使用授权头将 "authToken" 传递给服务器。必须使用 "Bearer"认证方案传递令牌。

C: GET /some/resource HTTP/1.1
   Host: server.example.com
   Authorization: BEARER authToken=xxyyzz
   [...]

认证机制

本节列出支持的验证方案。符合规定的客户端和服务器必须为本文档中定义的特定验证方案实施认证交换。

所有客户端和服务器必须支持使用SHA-256的SCRAM作为哈希功能。

以下认证参数对所有认证方案都有效

SCRAM

'SCRAM' auth计划须用于认证使用Salted Challenge响应认证机制(SCRAM)客户端。SCRAM在 [RFC5802]`#references 中定义。

要使用的加密哈希函数在服务器对hello消息的响应中指定为auth参数。不管使用哪个哈希函数,认证交换消息是相同的,并在下面定义。本文档中使用的方法是基于实验的"Salted Challenged Response HTTP Authentication Mechanism" RFC7804

在这个例子中,用户名是"user",密码是"pencil"。SHA-256用作加密散列函数。

Hello

注意:标题行已被拆分以便于可读性。所有base64url编码都没有填充。

客户端发送一个hello消息,指示将其自身标识为"用户"。

C: GET /haystack/about HTTP/1.1
   Host: server.example.com
   Authorization: HELLO username=dXNlcg

服务器响应,指示客户端应使用SCRAM进行身份验证。

S: HTTP/1.1 401 Unauthorized
   WWW-Authenticate: SCRAM hash=SHA-256, handshakeToken=aabbcc

验证交换

客户端启动认证交换。授权头指定了SCRAM作为认证方案。指定以下属性:

C: GET /haystack/about HTTP/1.1
   Host: server.example.com
   Authorization: SCRAM handshakeToken=aabbcc
       data=biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8K

服务器响应客户端具有以下属性:

S: HTTP/1.1 401 Unauthorized
   WWW-Authenticate: SCRAM handshakeToken=authAABBCC, hash=SHA-256
       data=cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJ
           bGopaE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYK

客户端继续与另一个GET /haystack/about进行认证交换。指定以下属性:

C: GET /haystack/about HTTP/1.1
   Host: server.example.com
   Authorization: SCRAM handshakeToken=authAABBCC,
       data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ
           0FmdXhGSWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empm
           TUhnc3FtbWl6N0FuZFZRPQo

最终的服务器消息指示用户被认证。由于这是最终的服务器消息,所以它按照 Auth Token 部分所述以200(Ok)进行响应。指定以下属性:

S: HTTP/1.1 200 Ok
   Authentication-Info: authToken=AuthenticatedTokenXXYYZZ, hash=SHA-256
       data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQo

References

RFC4648: Base16,Base32,Base64数据编码

RFC5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanism

RFC7235: 超文本传输​​协议(HTTP/1.1):认证

RFC7615: HTTP身份验证信息和代理身份验证信息响应头字段

RFC7804: Salted Challenge Response HTTP 认证机制

Ops VFDs