使用令牌（Java）保护REST Web服务 [英] Securing REST Web Service using token (Java)

问题描述

这个问题在某种程度上与下面的链接问题有关。但是，我需要对某些方面和一些其他信息更加清晰。参考：
REST Web服务身份验证令牌实现

This question is in some way related to the below linked question. However, I need a little more clarity on some aspects and some additional information. Refer: REST Web Service authentication token implementation

背景：

• 我需要使用令牌来实现REST Web服务的安全性


• Web服务旨在与Java客户端一起使用。因此，形式
  认证和弹出窗口的凭据是没有用的。


• 我是REST的安全和加密新功能

这是我迄今为止所了解的：

This is what I have understood till now:

对于第一个请求：

1. 用户建立https连接（或容器确保https使用
   301）


2. 用户POST登录服务的用户名和密码


3. 如果凭据有效我们：
   
   
   
   
   • 生成随机临时令牌
   
   
   • 将随机标记存储在服务器将其映射到实际用户名
   
   
   • 使用仅对服务器已知的对称密钥加密令牌
   
   
   • 将加密令牌
   
   
   • 将加密的令牌和哈希发送到客户端
   
   

1. User establishes https connection (or container ensures https using 301)
2. User POSTs username and password to login service
3. If credentials are valid we:
   • Generate a random temporary token
   • Store the random token on server mapping it to actual username
   • Encrypt the token using a symmetric key only known to server
   • Hash the encrypted token
   • Send the encrypted token and the hash to the client

后续请求：

1. 客户端发送加密的令牌和散列组合（使用
   用户名字段的基本？）


2. 我们确保加密ted令牌没有被篡改使用哈希和
   然后解密它


3. 我们检查会话跟踪表中的解密令牌
   未过期条目，获取实际的用户名（通过代码来管理
   的到期时间）


4. 如果找到用户名，根据允许的角色，允许的操作
   已配置

1. Client sends this encrypted token and hash combination (using username field of basic?)
2. We make sure the encrypted token is not tampered using the hash and then decrypt it
3. We check the decrypted token in the session-tracking-table for a not-expired entry and get the actual username (expiry to be managed by code?)
4. If the username is found, based on allowed roles, allowed operations are configured

更多细节：

1. 由于客户端是一个java客户端，第一个请求可以是包含凭据的POST
   。但是，这看起来可能会在https建立之前暴露
   的凭据。因此，应该
   有一个安全资源的虚拟GET，以便https首先建立
   ？


2. 假设上述是必需的，第二个请求是一个LoginAction POST
   带凭证。此请求是手动处理的（不使用
   容器的授权）。这是正确的吗？


3. 上述LoginAction返回用户加密的
   令牌+哈希


4. 的组合用户将其设置为由BASIC认证使用
   机制（字段用户名）


5. 我们实现一个JAASRealm来解密和验证令牌，并找到
   允许的角色


6. 其余的授权过程由容器
   与Web.xml中定义的WebResourceCollection进行关联

1. Since client is a java client, the first request can be a POST containing the credentials. However, this looks like it may expose the credentials before the https gets established. Hence should there be a dummy GET to a secured resource so that https is established first?
2. Assuming above is required, the second request is a LoginAction POST with credentials. This request is handled manually (not using container's authorisation). Is this right?
3. The above LoginAction returns the user the combination of encrypted token + hash
4. User sets it to the header that is used by BASIC authentication mechanism (field username)
5. We implement a JAASRealm to decrypt and validate the token, and find the roles allowed
6. The rest of authorisation process is taken care of by the container with the WebResourceCollection defined in the web.xml

$ b $这是正确的方法吗？

Is this the correct approach?

推荐答案

为什么不简化为以下？

请求：

1. 用户建立到服务器的HTTPS连接（服务不监听任何
   其他端口）和POSTs凭据登录服务。


2. 服务器回复 HSTS标题，以确保进一步通信
   是HTTPS。


3. 如果凭据有效我们：
   
   
   
   
   • 生成一个随机的临时令牌，使用 CSPRNG 安全生成。将这个长度足够安全（128位）。
   
   
   • 将服务器上的随机标记存储到映射到实际用户名。
   
   
   • 发送随机标记到客户端
   
   

1. User establishes HTTPS connection to server (service does not listen on any other ports) and POSTs credentials to login service.
2. Server replies with HSTS header to ensure all further communication is HTTPS.
3. If credentials are valid we:
   • Generate a random temporary token which is securely generated using a CSPRNG. Make this long enough to be secure (128 bit).
   • Store the random token on server mapping it to actual username.
   • Send the random token to the client

对于后续请求：

1. 客户端通过HTTPS在自定义HTTP头中发送令牌。


2. 令牌位于数据库中并映射到用户名。如果发现访问是基于允许的角色和允许的操作配置的。


3. 如果没有找到用户被认为是未经身份验证的，并且必须再次使用登录服务进行身份验证才能获得新的令牌。 >
   

1. Client sends token in a custom HTTP header over HTTPS.
2. Token is located in the DB and mapped to the username. If found access is configured based on allowed roles and allowed operations.
3. If not found user is considered unauthenticated and will have to authenticate with the login service again to get a new token.

在服务器端，令牌将以过期日期存储。在每次访问服务时，将更新此日期以创建滑动过期。将会有一个工作将每隔几分钟运行一次，以删除过期的令牌，并且检查令牌的有效会话的查询将仅检查那些未被认为已过期的工作（如果计划的作业由于任何原因而失败，则可防止永久会话）

On the server side the token will be stored with an expiry date. On each access to the service this date will be updated to create a sliding expiration. There will be a job that will run every few minutes to delete expired tokens and the query that checks the token for a valid session will only check those that have not deemed to have expired (to prevent permanent sessions if the scheduled job fails for any reason).

不需要哈希和加密数据库中的令牌 - 它不会增加真正的价值，除了触摸通过晦涩的安全。你可以只是哈希。这将防止设法从会话数据表中获取的攻击者劫持现有的用户会话。

There is no need to hash and encrypt the tokens within the database - it adds no real value apart from a touch of security through obscurity. You could just hash though. This would prevent an attacker that managed to get at the session data table from hijacking existing user sessions.

这篇关于使用令牌（Java）保护REST Web服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！