【问题标题】:How to do Basic Authentication of a resource in Dropwizard如何在 Dropwizard 中对资源进行基本身份验证
【发布时间】:2017-07-23 21:24:04
【问题描述】:

我相信我的基本身份验证工作正常,但我不确定如何保护资源,以便只有在用户登录时才能访问它们。

public class SimpleAuthenticator implements Authenticator<BasicCredentials, User> {
    UserDAO userDao;

    public SimpleAuthenticator(UserDAO userDao) {this.userDao = userDao;}

    @Override
    public Optional<User> authenticate(BasicCredentials credentials) throws AuthenticationException    
    {
        User user = this.userDao.getUserByName(credentials.getUsername());
        if (user!=null &&
                user.getName().equalsIgnoreCase(credentials.getUsername()) &&
                BCrypt.checkpw(credentials.getPassword(), user.getPwhash())) {
            return Optional.of(new User(credentials.getUsername()));
        }
        return Optional.absent();
    }
}

我的登录资源是这样的:

@Path("/myapp")
@Produces(MediaType.APPLICATION_JSON)
public class UserResource {
    @GET
    @Path("/signin")
    public User signin(@Auth User user) {
        return user;
    }
}

我用以下方式为用户签名:

~/java/myservice $ curl -u "someuser" http://localhost:8080/myapp/signin
Enter host password for user 'someuser':
{"name":"someuser"}

问题

假设用户使用/myapp/signin 端点从浏览器或本机移动应用前端登录。那么我该如何保护另一个端点,例如/myapp/{username}/getstuff,它需要用户登录

@GET
@Path("/myapp/{username}/getstuff")
public Stuff getStuff(@PathParam("username") String username) {
    //some logic here
    return new Stuff();
}

【问题讨论】:

    标签: java rest authentication dropwizard


    【解决方案1】:

    当您尝试实施 REST 时,有两件事。一个是身份验证(似乎你已经让它工作了),另一个是授权(我相信你的问题是)。

    我之前在 dropwizard 中处理它的方式是,每次用户登录时,您都会将某种 access_token(这证明他们已通过身份验证)返回给客户端,他们必须在他们作为某些标头的一部分(通常这是通过“授权”标头完成的)。在服务器端,您必须先将此 access_token 保存/映射到该用户,然后再将其返回给客户端,并且当使用该 access_token 进行所有连续调用时,您查找使用该 access_token 映射的用户并确定该用户是否是否有权访问该资源。现在举个例子:

    1) 用户使用 /myapp/signin 登录

    2) 您对用户进行身份验证并将 access_token 作为响应发送回,同时将其保存在您身边,例如 access_token --> userIdABCD

    3) 客户端返回到 /myapp/{username}/getstuff。如果客户端没有在“Authorization”标头中提供您给他们的 access_token,您应该立即返回 401 Unauthorized code。

    4) 如果客户端确实提供了 access_token,您可以根据您在步骤#2 中保存的 access_token 查找用户,并检查该 userId 是否有权访问该资源。如果没有,则返回 401 未授权代码,如果确实有访问权限,则返回实际数据。

    现在是“授权”标题部分。您可以使用“@Context HttpServletRequest hsr”参数在所有调用中访问“Authoroziation”标头,但在每次调用中添加该参数是否有意义?不,它没有。这是安全过滤器在 dropwizard 中的帮助。这是一个如何添加安全过滤器的示例。

    public class SecurityFilter extends OncePerRequestFilter{
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException{
    String accessToken = request.getHeader("Authorization");
    // Do stuff here based on the access token (check for user's authorization to the resource ...
    }
    

    现在,这个安全过滤器真正保护了哪些资源?为此,您需要将此过滤器添加到要保护的特定资源中,具体操作如下:

    environment.addFilter(SecurityFilter, "/myapp/*");
    

    请记住,您的网址 /myapp/signin 和 /myapp/{username}/getstuff 都将通过此安全过滤器,但是 /myapp/signin 将没有 access_token,显然是因为您没有t 还没有给客户。这必须在过滤器本身中加以处理,例如:

    String url = request.getRequestURL().toString();
    if(url.endsWith("signin"))
    {
    // Don't look for authorization header, and let the filter pass without any checks
    }
    else
    {
    // DO YOUR NORMAL AUTHORIZATION RELATED STUFF HERE
    }
    

    您要保护的网址取决于您的网址的结构以及您要保护的内容。您设计的 url 越好,就越容易编写安全过滤器来保护它们。添加此安全过滤器后,流程将如下所示:

    1) 用户转到 /myapp/signin。该调用将通过过滤器,并且由于该“if”语句,它将继续到您的 /myapp/signin 的 ACTUAL 资源,并且您将根据成功的身份验证分配一个 access_token

    2) 用户使用 access_token 调用 /myapp/{username}/mystuff。此调用将通过相同的安全过滤器,并将通过您实际进行授权的“else”语句。如果授权通过,会继续调用你实际的资源处理程序,如果没有授权,应该返回 401。

    public class SecurityFilter extends OncePerRequestFilter
    {
    
        @Override
        protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException
        {
            String url = request.getRequestURL().toString();
            String accessToken = request.getHeader("Authorization");
            try
            {
                if (accessToken == null || accessToken.isEmpty())
                {
                    throw new Exception(Status.UNAUTHORIZED.getStatusCode(), "Provided access token is either null or empty or does not have permissions to access this resource." + accessToken);
                }
                if (url.endsWith("/signin"))
                {
        //Don't Do anything
                    filterChain.doFilter(request, response);
                }
                else
                {
        //AUTHORIZE the access_token here. If authorization goes through, continue as normal, OR throw a 401 unaurhtorized exception
    
                    filterChain.doFilter(request, response);
                }
            }
            catch (Exception ex)
            {
                response.setStatus(401);
                response.setCharacterEncoding("UTF-8");
                response.setContentType(MediaType.APPLICATION_JSON);
                response.getWriter().print("Unauthorized");
            }
        }
    }
    

    我希望这会有所帮助!我自己花了大约 2 天的时间才弄清楚这一点!

    【讨论】:

    • 太棒了。感谢您的精彩解释。两个问题:1)您每次都使用什么来创建唯一的会话ID? UUID? 2)你用什么来存储 sessionIds 并将它们与进来的那些匹配?哈希映射?
    • 当您说唯一会话 id 时,您到底是什么意思?访问令牌?如果是这样,是的,我使用 UUID 作为访问令牌。这些访问令牌每小时过期一次(我使用的是 OAuth,因此这是根据标准,对于基本身份验证它可能会有所不同),因此在集群环境中,它们不会存储在内存中,而是一直存储到数据库中。我们使用 couchbase (NoSql) 数据库,所以基本上整个数据库对我们来说是一个巨大的 Hashmap :)。如果您在内存中执行此操作,在集群环境中,您将开始遇到跨应用服务器管理此内存映射的问题。
    • 忘了说。 REST 根据标准是无状态的,因此没有会​​话 ID(尽管有时我看到人们也在 REST 中实现会话......不推荐)。每个请求都是无状态的,并且要授权每个请求,必须完成某种令牌(或每个请求的基本身份验证)。
    • 很高兴知道。现在我没有设想一个集群环境。我只会一个应用服务器,所以我现在只是将令牌保存在内存映射中。最后,您是否允许用户使用 OAuth 进行注册?您介意分享一下您是如何在 gist 中实现 OAuth 的吗?再次感谢
    • 另外,在你上面的 sn-p. OncePerRequestFilter 是什么?
    【解决方案2】:

    对不起,作为一个简单的用户。我相信您可以通过使用@Auth User 用户来保护资源

    public Service1Bean Service1Method1(
        @Auth User user,
        @QueryParam("name") com.google.common.base.Optional<String> name) {
    

    【讨论】:

    • 是的,您可以通过这种方式保护资源,但正如@xmenymenzmen 所提到的,这只是身份验证,而不是授权。
    猜你喜欢
    • 2014-04-20
    • 2017-09-18
    • 1970-01-01
    • 2015-03-22
    • 2014-11-23
    • 1970-01-01
    • 2016-06-17
    • 2015-08-12
    • 2017-06-13
    相关资源
    最近更新 更多