Jarrod Carlson (Migrated from SEC-1393) said:
At least one portion of my application requires access to an AuthenticationTrustResolver instance. For now, I can simply inject my class with an instance of AuthenticationTrustResolverImpl created manually in my bean context. Since I am not customizing or extending the default implementation, this is fine for now.
However, the instance I create in my bean context is not shared with the ExceptionTranslationFilter, and as far as I can tell, there is no way to configure the ExceptionTranslationFilter to use the manually created instance. (Unless I want to configure the entire filter stack myself, in which case it would be possible, but that seems a bit unreasonable to me).
Also, it would be helpful if the default AuthenticationTrustResolver created for/by the ExceptionTranslationFilter could be exposed via an alias for other parts of the application to reuse.
Might I suggest one of the following attribute additions to the namespace?
<!-- either 'ref' or 'alias', but not both? -->
Luke Taylor said:
What is the use case that you envisage whereby someone would want to use a custom AuthenticationTrustResolver in combination with the namespace?
Jarrod Carlson said:
I do not currently have a use case where I would need a custom AuthenticationTrustResolver.
However, I do currently have a use case where I need an AuthenticationTrustResolver instance in my code, which is the main goal in this ticket. In the Spring spirit, it would seem to make more sense to reuse an existing instance than to hand-code a bean definition, or worse, instantiate one in my code directly.
The secondary, non-goal in this ticket of providing your own AuthenticationTrustResolver implementation was simply for consistency in that most other portions of the Spring Security filter stack can be configured, exposed, or replaced with alternative implementations.
Ok, then I don't really see a strong case for adding this to the namespace. It is not a common requirement and adding a bean manually only requires a single line of configuration. We always prefer to keep the namespace as simple as possible and have it cater for the most common use cases which people encounter and those where the gain in terms of reduced configuration is substantial.
In our project we need an ability to replace existing AuthenticationTrustResolverImpl with our custom AuthenticationTrustResolver implementation.
We need it because we replaced AnonymousAuthenticationFilter with custom implementation. This implementation creates new user for every anonymous and persists it in DB. Newly created user gets role ROLE_ANONYMOUS. So user can interact with website and being tracked without explicit registration. After explicit registration user gets another role ROLE_USER and a password.
So we always have authenticated user but with different roles. And we need AuthenticationTrustResolver to be based on user role rather then on user class.