AngularJS - Безопасность Java EE REST

Question

Я использую AngularJS вместе с REST API на бэкэнд Java EE 7. Проект будет развернут на Wildfly сервере приложений и у меня есть некоторые вопросы пересортицы ценных бумаг:

1. для шифрования/дешифрования данных Я использую CryptoJS для шифрования и дешифрования на стороне сервера (Java), но, видимо, мы должны послать кодовая фраза в чистом виде, шифр и соль шифруются только. Вопрос: почему кодовая фраза - это чистый текст? это должно быть секретным, а затем зашифрованным, а?

2. Для API REST, какой стандарт использовать для Java EE 7, заголовок безопасности HTTP (basic-auth)? Значок доступа Json? и как это работает, где хранить пользовательский сеанс/токен, в cookie? Я просто хочу знать, как это сделать с помощью Angular.

3. Возможно, я могу использовать классический JAAS с аутентификацией на основе форм, а затем, чтобы аутентификация на сервере была проверена на request.login(), тогда мой EJB будет защищен @Role.

4. Какова защита страниц в AngularJS? На данный момент я использую web.xml и помещаю шаблоны URL, возможно, есть лучший способ?

Я уже нашел много примеров, как это:

AngularJs and Jboss and JAAS (omnisecurity)

how to integrate angularjs and java jaas based authentication?

Некоторые пользователи упоминает об этом:

* index.html page should contain token inside html to avoid CSRF 
* token shouldn't be stored in a cookie storage 
* Each request should be signed with header param 
* Server should validate every request by passed header 
* If cookie usage is a must you should validate referer in order to prevent CSRF 

Но не конкретно пример о том, как реализовать это, esp в особенности CSRF.

Answer 1

Для шифрования/дешифрования данных Я использую CryptoJS для шифрования и дешифрования на стороне сервера (Java), но, по-видимому, мы должны послать ключевую фразу в ясной, шифра и соль только в зашифрованном виде. Мой вопрос: почему кодовая фраза - это чистый текст? он должен быть секретным, а затем зашифрован как ну нет?

Как только вы отправляете ключ (кодовую фразу?) В ясном виде - шифрование бесполезно.

Для обеспечения разумной защиты клиент-сервер используйте HTTPS. Простой, эффективный и безопасный. Как правило, это плохая идея для шифрования на стороне веб-приложения, поскольку пользователь или «человек в середине» может извлекать или изменять ключ и данные.

В другом случае это сквозная защита, когда клиент шифрует сообщения зашифрованных данных, и они хранятся/обрабатываются в том виде, в каком они есть, причем ключ шифрования доступен только пользователю. Если это не так, и служба нуждается в данных для дальнейших операций, HTTPS - это путь.

Для API REST, какой стандарт использовать для Java EE 7, заголовок безопасности HTTP (basic-auth)? Значок доступа Json? и как это действительно работает , где хранить пользовательский сеанс/токен, в cookie? Я просто хочу, чтобы знал, как это сделать с Угловым.

Фактически вы указали параметры. Это ваше решение. У каждого варианта есть свои плюсы и минусы. В основном - если вы говорите о службах (REST), не имеет значения, какая технология используется.

Для служб REST вызывается непосредственно из браузера я опускаем базовая аутентификация (в противном случае пользователь получит окно аутентификации всплывающей)

Вы можете использовать маркер JWT (подписанный секрету приложения, просто добавьте некоторую дату истечения срока действия), но тогда вы не можете «выйти из системы» пользователя, просто дождитесь окончания токена. Преимущество состоит в том, что токен является «самодостаточным», и вам не нужно беспокоиться об управлении сеансом. Клиент отправляет токен JWT в HTTP-заголовке авторизации, вы просто декодируете его, проверяете, а затем можете взять идентификатор из токена.

Другой вариант - это токен сеанса (cookie или отправляется как заголовок авторизации), где вам необходимо управлять сеансами (хранить токены, очищать токен при выходе из системы, ...). Использование cookie сеанса сервера приложений делает ваши сервисы непригодными для использования другими приложениями (все еще вопрос - хотите ли вы/нужны услуги для повторного использования третьими лицами), но вы получаете встроенную авторизацию (JAAS, Roles, ...).

Может быть, я могу использовать классические JAAS с проверкой подлинности на основе форм и затем с request.login() на стороне сервера для аутентификации, то мой EJB все будет защищена @Role.

Действительно, это способ аутентификации и авторизации пользователя и выдачи токена (jwt, cookie, other ...).

Как защитить страницы в AngularJS? На данный момент я с использованием web.xml и размещения шаблонов URL, возможно, есть лучший способ ?

Авторизация по умолчанию должна быть в порядке.

По-прежнему - прост. Согласно моим опытам, статические ресурсы (веб-страницы, изображения, скрипты, css) должны быть статичными, и не имеет большого значения, являются ли они общедоступными. Важным является выполнение (операции, данные, ...) в качестве служб, и это тот момент, когда вы выполняете правильную проверку подлинности и авторизацию.

Удачи!