Думаю, для аутенфикации по своей схеме надо указать свой провайдер (от интерфейса AuthenticationProvider), само собой определить свой Authentication (7 переопределенных методов) и UserDetailsServices (1 переопределенный метод). А для кастомной реализации RememberMe использовать класс, имплементирующий RememberMeServices (можно банально взять TokenBasedRememberMeServices и внести нужные изменения). Из опыта работы определения этих четырех классов хватает для создания кастомной авторизации и кастомного RememberMe. В кастомный UserDetailsServices можно инжектить нужный ДАО для работы с базой, который используется для переопределенного loadUserByUsername().

Естественно, нет. И это правильно. Не вдавался в код конкретно этого класса, но если в качестве UserDetail (я так понимаю, речь об этом) хранить пользователя со всеми параметрами (имярек, мыло, картинки и прочее), то нарываемся на следующее противоречие при использовании Spring Security, скажем, в контроллерах: для идентефикации пользователя-принципала он вычитывается из базы один раз при открытии веб-сессии и далее хранится в этой сессии (principal в Authentication). Если поменять сущность (данные в таблицы), то надо переавторизироваться, тогда как данные пользователя могут подлежать частой перезаписи и использоваться не так активно. Поэтому имеет смысл держать объект AuthUser, содержащий авторизационные данные, и User с любым набором данных, и связать их даже связью Один-к-одному, и при необходимости в методе контроллера подгружать объект User, получая его из параметров (AuthUser) authentication.getPrincipal().

Изначально также использовал единый объект пользователя, используя и как авторизационный, и как набор свойств, но столкнулся с тем, что при изменении свойства пользователя приходится вручную переавторизовываться, чтобы в другом методе контроллера получить обновленный объект пользователя. По-моему, это нелогично и значительно более затратно. Так и пришел к такой схеме, хотя, по-видимому, она так и используется в стандартных классах SS, но я не обратил сразу на это внимания. Если поможет, то свои поиски я изложил в статье на Хабре более года назад - многие вещи сейчас кажутся неправильными и я бы уже делал по-другому, но цепочка создания кастомной авторизации может помочь.

rdmIDVsbruck, согласен, но hibernate связь one-to-one грузит сразу без lazy. Т.е. разделить не получиться, если я правильно понимаю.
Ну, можно и lazy, никто не мешает.
В последнем проекте я пошел по противоречивому пути, не обеспечивая целостность базы внутренними связями, в большинстве своем только наличием ссылочного идентефикатора в "зависимой" таблице. Таким образом, в AuthUser есть только id, и User я успешно загружаю запросом. Решение крайне противоречивое, но специфика Хибернейта тащить "очень-очень много" и сложность контролировать это при сильно раздутой структуре заставили обратиться к инфе по решениям в соцсетях, где в большинстве своем используется именно такой подход, причем, он не ограничен одной базой - с независимыми ключами просто использовать параллельно NoSQL-базу для хранения, скажем, большого объема справочной информации (словарей).