Транспорт-гарантия CONFIDENTIAL игнорируется при наличии других ограничений безопасности

Question

У меня работает веб-сервис JAX-RS, и я хочу защитить его все, используя безопасные соединения. Поэтому я добавил это к моему web.xml:

<security-constraint> 
    <web-resource-collection> 
     <web-resource-name>Prohibit unsecured HTTP</web-resource-name> 
     <url-pattern>/*</url-pattern> 
    </web-resource-collection> 
    <user-data-constraint> 
     <transport-guarantee>CONFIDENTIAL</transport-guarantee> 
    </user-data-constraint> 
</security-constraint> 

Это работает все хорошо и денди (с перенаправлением от HTTP к HTTPS настроен в моем EAP standalone.xml, но я, вероятно, превратить его в выключенном состоянии).

Однако, когда я теперь хочу установить BasicAuth для некоторых ресурсов я добавить еще один, более узкое ограничение:

<security-constraint> 
    <web-resource-collection> 
     <web-resource-name>Project editing</web-resource-name> 
     <url-pattern>/projects</url-pattern> 
     <url-pattern>/projects/*</url-pattern> 
     <http-method>POST</http-method> 
     <http-method>PUT</http-method> 
     <http-method>PATCH</http-method> 
     <http-method>DELETE</http-method> 
    </web-resource-collection> 
    <auth-constraint> 
     <role-name>AUTH_USER</role-name> 
    </auth-constraint> 
</security-constraint> 

затем внезапно запросов к этим адресам й запросов GET даже не упоминаются здесь- является счастливо обслуживается через HTTP.

Если я правильно понимаю EE6 documentation, то в случае нескольких ограничений безопасности он будет сочетать url-шаблоны и http-методы. Но он ничего не говорит о транспортной гарантии.

Как я могу это решить? HTTPS везде и BasicAuth по некоторым URL-адресам?

Answer 1

Я попробовал эти две альтернативы до сих пор:

1) Добавить Секретно гарантии также второй безопасности-ограничения. Это помогло на полпути. Теперь POST, PUT и т. Д. Являются HTTPS-only, но запросы GET для «проектов» по-прежнему проходят через HTTP.

Это может быть исправлено путем добавления третьего блока ограничений безопасности, который определяет CONFIDENTIAL, но не аутентификации для запросов GET, но это кажется интуитивно неправильным и невероятно трудно поддерживать.

2) Винт web.xml и отклонять HTTP-запросов с помощью @WebFilter вместо:

@WebFilter(filterName = "NoHttpFilter", urlPatterns = { "/*" }) 
public class NoHttpFilter implements Filter { 

    public void init(FilterConfig config) throws ServletException { 
    } 

    @Override 
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { 
     HttpServletRequest requ = (HttpServletRequest) req; 
     if (!requ.isSecure()) { 
      HttpServletResponse resp = (HttpServletResponse) res; 
      resp.reset(); 
      resp.sendError(404, "If you're not speaking HTTPS, I'm not listening."); 
     } else { 
      chain.doFilter(req, res); 
     } 
    } 

    public void destroy() { 
    } 
} 

Это на самом деле работает как шарм, но, к сожалению, работает после BasicAuth, поэтому звонки в защищенных местах будет первым спросить за пароль, а затем отказаться от записи на основе протокола.