Uploaded image for project: 'Spring Security'
  1. Spring Security
  2. SEC-1393

Add namespace configuration for AuthenticationTrustResolver

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 3.0.2
    • Component/s: Namespace
    • Labels:
      None

      Description

      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 <http> namespace?

      <http trust-resolver-ref="myTrustResolver" />

      or

      <http trust-resolver-alias="exportedTrustResolverName" />

      or

      <http>
      <!-- either 'ref' or 'alias', but not both? -->
      <trust-resolver ref="myTrustResolver" alias="exportedTrustResolverName" />
      </http>

        Activity

        Hide
        luke Luke Taylor added a comment -

        What is the use case that you envisage whereby someone would want to use a custom AuthenticationTrustResolver in combination with the namespace?

        Show
        luke Luke Taylor added a comment - What is the use case that you envisage whereby someone would want to use a custom AuthenticationTrustResolver in combination with the namespace?
        Hide
        jcarlson Jarrod Carlson added a comment -

        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.

        Show
        jcarlson Jarrod Carlson added a comment - 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.
        Hide
        luke Luke Taylor added a comment -

        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.

        Show
        luke Luke Taylor added a comment - 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.
        Hide
        a2256064 Mikhail added a comment -

        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.

        Show
        a2256064 Mikhail added a comment - 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.

          People

          • Assignee:
            luke Luke Taylor
            Reporter:
            jcarlson Jarrod Carlson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: