I_suss

Давно писал вот, такой код.
Должен сработать.

@GetMapping("/")
  public String homepage(Model model) {

    // Проверяем авторизован ли пользователь и если авторизован, то редиректим его в /dashboard
    if (SecurityContextHolder.getContext().getAuthentication() != null
        && SecurityContextHolder.getContext().getAuthentication().isAuthenticated()
        && !(SecurityContextHolder.getContext().getAuthentication()
            instanceof AnonymousAuthenticationToken)) {

      return "redirect:/dashboard";
    }

    return "index";
  }

Вы выделили в системе два класса сущностей. Одна - Пользователь, вторая - Роль.
Под каждый класс нужна отдельная таблица.
Как определить какие взаимоотношения между этими классами?
Нужно примерить следующие коммутативные гипотезы:
Первая пара гипотез:
"Один пользователь должен (может) иметь только одну роль."
"Одна роль должна (может) быть назначена многим пользователям."
Вторая пара гипотез:
"Один пользователь должен (может) иметь несколько ролей."
"Одна роль должна (может) быть назначена многим пользователям."
Если в вашей архитектуре системы справедлива первая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "один ко многим". Это значит, что у таблицы Пользователь будет внешний ключ в виде идентификатора роли, тем самым вы каждому пользователю сможете назначить только одну роль. Но сами роли могут повторятся у разных пользователей.
Если в вашей архитектуре системы справедлива вторая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "многим ко многим". Для этого нужно создать промежуточную таблицу, например Пользователь_и_роль, в которой будут два внешних ключа - идентификатор пользователя и идентификатор роли пользователя (можно, но технически нужно еще создать еще идентификатор первичного ключа, чтобы можно было корректно обращаться к записям этой таблицы, не путая их). В этом случае каждому пользователю можно выделить целый набор ролей, не ограничиваясь одной ролью.

На самом деле необязательно писать ROLE_
Все зависит от метода, который вы используете. Если используете hasAuthority, то при проверке вам нужно к роли добавить ROLE. Например, hasAuthority("ROLE_ADMIN") Если же используете hasRole("ADMIN")
Role является разновидностью authority

Мда. Любители крестов - мозохисты. Я-бы так написал.

using namespace std;

cout << "-Меню-\n";

Лаконично?

И зачем вам такой перевод строки?
Что, хотите под DOS и Mac сразу писать? Готов спорить что не грозит.

А это что?
LogPassword == Password
Пароли так никто не проверяет. Есть функция которая сверяет хеши паролей. Потому что их не хранят никогда.
В базе тоже их не хранят.

А это что?
std::ofstream Data("Data.txt");
Всё пишем в один файл? Всех пользователей? И файл переписывается?

1) (Вкусовщина) стиль наименования не самый удачный. И переменные и функции называются одинаково - каждое слово с большой буквы без разделителей. Во всех массово применяемых стилях обычно переменные, функции и константы называются по разному. Например, переменные можно называть log_password. Функции и так оставить с большой буквы, а константы - полностью большими буквами.

2) обилие вложенных if. Практикуйте ранний выход. Например в Login() можно сделать так:

if (Data.is_open()) {
  std::cout << "Ошибка. У вас нет аккаунта" << std::endl;
  return;
}

И весь оставшийся код оказывается на 1 уровень выше.

3) Бесконечные рекурсивные вызовы - это плохо. Рано или поздно программа упадет с закончившимся стеком.
У вас Menu вызывает Login, который опять вызывает Menu. Да и сам Menu тоже.

Лучше сделать в Menu бесконечный цикл (while(true)) и или выходить из программы через exit(), или возвращать из Login, что надо завершаться и тогда в Menu делать break.