Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1393: Add namespace configuration for AuthenticationTrustResolver #1636

spring-issuemaster opened this Issue Jan 31, 2010 · 4 comments


None yet
1 participant

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?



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.

Luke Taylor said:

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.

Mikhail said:

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.

@spring-issuemaster spring-issuemaster added this to the 3.0.2 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment