Spring Security : хранение пользователей в БД. часть 2

Предварительно прочитать:
SS: хранение пользователей в БД. часть 1
В этой части мы рассмотрим возможность объеденения ORM фреймворка (например hibernate) вместе со Spring Security. При этом будут использоваться аннотации.
Итак, lets go.
Если вы желаете хранить пользователей в своих таблицах, а не предлагаемых SS-ом и желаете обращатся к ним с помощью hibernate? тогда вам надо:

1) Реализовать интерфейс UserDetailsService, в котором аж одна функция loadUserByUsername. У меня этот интерфейс обращается к моим dao классам , с помощью которых и извлекает информацию о пользователях, например:
@Component
@Transactional
public class UserServiceImpl implements UserDetailsService {
    @Autowired
    UserDao userDao;
    @Override
    public UserDetails loadUserByUsername(String username)
            throws UsernameNotFoundException, DataAccessException {         
        return userDao.get(username);
    }
}

Особенность, обратите внимание , что функция loadUserByUsername возвращает не абы-шо , а некий объект UserDetails. Это между прочим тоже интерфейс.

2) Реализовать интерфейс UserDetails. SS рекомендует воспользоватся стандартным классом org.springframework.security.userdetails.User , в котором уже реализован этот интерфейс, но этот вариант далеко не всем подойдёт.
Если таки не подойдёт, надо реализовать несколько простых стандартных функций не представляющих большой интерес, аля: getUsername, getPassword, isEnabled, isCredentialsNonExpired, isCredentialsNonExpired, isAccountNonExpired. Причём последние 4 возвращают ложь или правду. Гораздо интересней функция getAuthorities(), а точнее то что она возвращает, а возвращает она массив GrantedAuthority... это между прочим тоже интерфейс, который нам придётся реализовывать :).

3) Реализовать интерфейс GrantedAuthority. Что это за интерфейс , и что это за единственная функция getAuthority() , которую надо реализовать? GrantedAuthority - это привилегия, роль, полномочие, ограничение которое получает пользователь на выполнение того или иного действия. Как задавать набор действий для каждой определённой роли в общем рассматривалось в первой заметке по SS , и более подробно будет рассматриватся в дальнейшем.
Основные используемые роли :
ROLE_ADMINISTRATOR, ROLE_USER, ROLE_SUPERVISOR, ROLE_WE_DONT_HAVE, ROLE_TELLER, ROLE_ANONYMOUS
Каждый пользователь может обладать не менее чем одной ролью. Поэтому в бд лучше всего иметь одну таблицу для данных пользователя и вторую для ролей. Первая таблица связана со второй в отношении один ко многим.

4) Последний штрих. Все классы написаны, осталось только настроить конфигурацию, для того, что-бы использовался нужный сервис получения пользователей. Это можно сделать в applicationContext-security.xml сделующим образом:
Регистрируем бин с классом реализующем UserDetailsService интерфейс:

    <beans:bean id="myUserDetailsService" class="path.to.UserServiceImpl" />   

В authentication-provider указываем какой сервис использовать для получения данных о пользователях:

    <authentication-provider user-service-ref='myUserDetailsService'/>

  Это всё.