Spring Security
  1. Spring Security
  2. SEC-1393

Add namespace configuration for AuthenticationTrustResolver

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor 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 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 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
        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
        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 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 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.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: