Рубрики
Без рубрики

Аутентификация хипстера с помощью внешней службы

Узнайте об использовании хипстерами Spring Security и о том, как это упрощает аутентификацию с помощью внешней службы.

Автор оригинала: Michael Pratt.

1. введение

По умолчанию приложения JHipster используют локальное хранилище данных для хранения имен пользователей и паролей. Однако во многих реальных сценариях может быть желательно использовать существующую внешнюю службу для проверки подлинности.

В этом уроке мы рассмотрим, как использовать внешнюю службу для аутентификации в Hipster. Это может быть любая известная служба, такая как LDAP, социальный логин или любая произвольная служба, которая принимает имя пользователя и пароль.

2. Аутентификация в JHipster

Хипстер использует Spring Security для аутентификации. Класс AuthenticationManager отвечает за проверку имени пользователя и паролей.

Менеджер аутентификации по умолчанию Authentication Manager в JHipster просто проверяет имя пользователя и пароль в локальном хранилище данных. Это может быть MySQL, PostgreSQL, MongoDB или любая из альтернатив, поддерживаемых Hipster.

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

2.1. Изменение аутентификации в JHipster

Но что, если у нас уже есть хранилище данных, содержащее имена пользователей и пароли, или служба, которая выполняет проверку подлинности для нас?

Чтобы предоставить пользовательскую схему аутентификации, мы просто создаем новый компонент типа Authentication Manager . Это будет иметь приоритет над реализацией по умолчанию.

Ниже приведен пример, в котором показано, как создать пользовательский Диспетчер аутентификации . У него есть только один метод для реализации:

public class CustomAuthenticationManager implements AuthenticationManager {
    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        try {
            ResponseEntity response =
                restTemplate.postForEntity(REMOTE_LOGIN_URL, loginRequest, LoginResponse.class);
            
            if(response.getStatusCode().is2xxSuccessful()) {
                String login = authentication.getPrincipal().toString();
                User user = userService.getUserWithAuthoritiesByLogin(login)
                  .orElseGet(() -> userService.createUser(
                    createUserDTO(response.getBody(), authentication)));
                return createAuthentication(authentication, user);
            }
            else {
                throw new BadCredentialsException("Invalid username or password");
            }
        }
        catch (Exception e) {
            throw new AuthenticationServiceException("Failed to login", e);
        }
    }
}

В этом примере мы передаем имя пользователя и учетные данные из объекта Authentication во внешний API.

Если вызов пройдет успешно, мы вернем новый UsernamePasswordAuthenticationToken , чтобы указать на успех. Обратите внимание, что мы также создаем запись локального пользователя, которую мы обсудим позже .

Если вызов завершается неудачно, мы выбрасываем некоторый вариант AuthenticationException , чтобы Spring Security изящно откатилась для нас.

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

3. Другие Соображения

До сих пор мы фокусировались на потоке аутентификации в Hipster. Но есть несколько других областей нашего приложения JHipster, которые мы должны изменить.

3.1. Код интерфейса

Код JHipster по умолчанию реализует следующий процесс регистрации и активации пользователя:

  • Пользователь регистрируется в учетной записи, используя свою электронную почту и другие необходимые данные
  • JHipster создает учетную запись и устанавливает ее как неактивную, а затем отправляет новому пользователю электронное письмо со ссылкой для активации
  • При переходе по ссылке учетная запись пользователя помечается как активная

Существует аналогичный процесс и для сброса пароля.

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

Поэтому нам необходимо принять меры для обеспечения того, чтобы эти функции управления учетными записями были недоступны пользователю .

Это означает удаление их из кода Angular или React, в зависимости от того, какой фреймворк используется в приложении JHipster.

Используя Angular в качестве примера, приглашение для входа по умолчанию включает ссылки на сброс пароля и регистрацию. Мы должны удалить их из app/shared/login/login.component.html :


You don't have an account yet? Register a new account

Мы также должны удалить ненужные пункты меню навигации из app/layouts/navbar/navbar.component.html :

и

Несмотря на то, что мы удалили все ссылки, пользователь все равно мог вручную перейти на эти страницы . Последний шаг-удалить неиспользуемые угловые маршруты из app/account/account.route.ts .

После этого должен остаться только маршрут настроек:

import { settingsRoute } from './';
const ACCOUNT_ROUTES = [settingsRoute];

3.2. API Java

В большинстве случаев достаточно просто удалить код управления учетной записью переднего плана. Однако чтобы быть абсолютно уверенным, что код управления учетными записями не вызывается, мы также можем заблокировать связанные API Java .

Самый быстрый способ сделать это-обновить класс Security Configuration , чтобы запретить все запросы к связанным URL-адресам:

.antMatchers("/api/register").denyAll()
.antMatchers("/api/activate").denyAll()
.antMatchers("/api/account/reset-password/init").denyAll()
.antMatchers("/api/account/reset-password/finish").denyAll()

Это предотвратит любой удаленный доступ к API-интерфейсам без необходимости удалять какой-либо код.

3.3. Шаблоны электронной почты

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

Например, мы можем отправить приветственное электронное письмо, когда пользователь впервые входит в систему. Шаблон по умолчанию включает в себя шаги для активации учетной записи, поэтому мы должны изменить его.

Все шаблоны электронной почты находятся в ресурсы/шаблоны/почта|/. Это HTML-файлы, которые используют Thymeleaf для передачи данных из кода Java в электронные письма.

Все, что нам нужно сделать, это отредактировать шаблон, чтобы включить нужный текст и макет, а затем использовать Почтовую службу для его отправки.

3.4. Роли

Когда мы создаем локальную запись пользователя JHipster, мы также должны позаботиться о том, чтобы у нее была хотя бы одна роль . Обычно для новых учетных записей достаточно роли USER по умолчанию.

Если у внешних поставщиков услуг есть собственное сопоставление ролей, у нас есть два дополнительных шага:

  1. Убедитесь, что в JHipster существуют любые пользовательские роли
  2. Обновите наш пользовательский Диспетчер аутентификации , чтобы установить пользовательские роли при создании новых пользователей

Hipster также предоставляет интерфейс управления для добавления и удаления ролей для пользователей.

3.5. Удаление учетной записи

Стоит отметить, что JHipster также предоставляет представление управления удалением учетных записей и API. Это представление доступно только пользователям-администраторам.

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

4. Заключение

В этом руководстве мы рассмотрели, как заменить код аутентификации JHipster по умолчанию нашей собственной схемой аутентификации. Это может быть LDAP, OIDC или любая другая служба, которая принимает имя пользователя и пароль.

Мы также видели, что использование внешней службы аутентификации также требует некоторых изменений в других областях нашего приложения JHipster. Это включает в себя интерфейсные представления, API и многое другое.

Как всегда, пример кода из этого учебника доступен на GitHub .