Incomplete separation of concerns in the Spring Security filter chain

Hi folks,

I am trying to implement a custom authentication scheme but I do not fully understand how Spring Security is intended to work (I read the manual twice and made a code review of the core and ldap modules).

As far as I can see, the chain goes like this:

1. entry point
2. filter
3. provider
4. user details service (which is handles implicitly by third)

Now, since authentication and authorization are two diffrent things:

1. why does the Authentication object contain granted authorities? This should be provided by an authorization layer to the authn layer. I miss an AuthoritiesPopulator interface. Only one for LDAP exists.
2. why has the authentication provider to spit out an authn object with a populated UserDetails object? This still has nothing to do with authentication.
3. why does the UserDetails contain a password field? This should be in the authentication object not in the userdetails.
4. why does the UserDetails class not extend the Principal class but simply use a username field? Since this class is not used by Spring Security for internal purposes, why does it has mandatory fields like authorities, username, password, etc? This is should be part of Authentication rather of UserDetails.

I am missing the seperation of concerns here. A clean structure would be, at least for me:

1. retrieve credentials from client
2. validate them, store credentials (as far as possible, e.g. an OTP shall not be stored)
3. get granted authorities for the user
4. get user details, if necessary at all (this is optional as far I understand)

Thanks and please comment,

Mike