Spring Security
  1. Spring Security
  2. SEC-1053

No way to give <authentication-provider>s bean ids

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.0.0 M1
    • Component/s: Core
    • Labels:
      None

      Description

      In Mule we allow people to wire in different authentication providers into the mule security manager. It seems with the <authentication-provider> bean definition parser you cannot give it a name. Instead one is generated for you. So we have no way to control which authentication provider gets used, we can only look for one in the application context.

        Activity

        Hide
        Luke Taylor added a comment -

        Can you give some more information on what you think is a bug here and what you're trying to do? For example, what is the mule security manager - is it Spring Security based?

        The <authentication-provider> element is quite limited in its scope. Users can easily add a conventional bean definition and link it into the Spring Security namespace with the <custom-authentication-provider> tag.

        Show
        Luke Taylor added a comment - Can you give some more information on what you think is a bug here and what you're trying to do? For example, what is the mule security manager - is it Spring Security based? The <authentication-provider> element is quite limited in its scope. Users can easily add a conventional bean definition and link it into the Spring Security namespace with the <custom-authentication-provider> tag.
        Hide
        Dan Diephouse added a comment -

        I wasn't aware of that - I'll look into it more. But, any reason I can't do:

        <authentication-provider id="foobar"> ...</authentication-provider> ?

        Seems like an unnecessary limitation.

        Show
        Dan Diephouse added a comment - I wasn't aware of that - I'll look into it more. But, any reason I can't do: <authentication-provider id="foobar"> ...</authentication-provider> ? Seems like an unnecessary limitation.
        Hide
        Luke Taylor added a comment - - edited

        The only (normal) use of an AuthenticationProvider with Spring Security is in configuring an instance of ProviderManager (the default AuthenticationManager).

        When you are using the namespace, the ProviderManager instance is maintained internally, hence the only normal configuration issue arising is how you add custom AuthenticationProvider instances to it. You also can expose the internal ProviderManager using the element <authentication-manager alias="someNameForUseInYourBeans"/>. So there would not normally be any reason for referring to a namespace-defined AuthenticationProvider by Id.

        Show
        Luke Taylor added a comment - - edited The only (normal) use of an AuthenticationProvider with Spring Security is in configuring an instance of ProviderManager (the default AuthenticationManager). When you are using the namespace, the ProviderManager instance is maintained internally, hence the only normal configuration issue arising is how you add custom AuthenticationProvider instances to it. You also can expose the internal ProviderManager using the element <authentication-manager alias="someNameForUseInYourBeans"/>. So there would not normally be any reason for referring to a namespace-defined AuthenticationProvider by Id.
        Hide
        Dan Diephouse added a comment -

        OK, custom-authentication-provider isn't really what I need. I stand by my assertion that <authentication-provider> should allow an ID. Take our configuration here for Acegi:

        <mule-ss:security-manager>
        <mule-ss:delegate-security-provider name="memory-dao" delegate-ref="daoAuthenticationProvider"/>
        </mule-ss:security-manager>

        <spring:bean id="inMemoryDaoImpl" class="org.springframework.security.userdetails.memory.InMemoryDaoImpl">
        <spring:property name="userMap">
        <spring:value>
        ross=ross,ROLE_ADMIN
        anon=anon,ROLE_ANONYMOUS
        </spring:value>
        </spring:property>
        </spring:bean>

        <spring:bean id="daoAuthenticationProvider" class="org.springframework.security.providers.dao.DaoAuthenticationProvider">
        <spring:property name="userDetailsService" ref="inMemoryDaoImpl"/>
        </spring:bean>

        I was hoping I could shorten this to:

        <mule-ss:security-manager>
        <mule-ss:delegate-security-provider name="memory-dao" delegate-ref="authProivder"/>
        </mule-ss:security-manager>

        <ss:authentication-provider id="authProivder">
        <ss:user-service>
        <ss:user name="ross" password="ross" authorities="ROLE_ADMIN" />
        <ss:user name="anon" password="anon" authorities="ROLE_ANON" />
        </ss:user-service>
        </ss:authentication-provider>

        But I still need to have DaoAuthenticationProvider around even if I use <custom-authentication-provider> it seems.

        Show
        Dan Diephouse added a comment - OK, custom-authentication-provider isn't really what I need. I stand by my assertion that <authentication-provider> should allow an ID. Take our configuration here for Acegi: <mule-ss:security-manager> <mule-ss:delegate-security-provider name="memory-dao" delegate-ref="daoAuthenticationProvider"/> </mule-ss:security-manager> <spring:bean id="inMemoryDaoImpl" class="org.springframework.security.userdetails.memory.InMemoryDaoImpl"> <spring:property name="userMap"> <spring:value> ross=ross,ROLE_ADMIN anon=anon,ROLE_ANONYMOUS </spring:value> </spring:property> </spring:bean> <spring:bean id="daoAuthenticationProvider" class="org.springframework.security.providers.dao.DaoAuthenticationProvider"> <spring:property name="userDetailsService" ref="inMemoryDaoImpl"/> </spring:bean> I was hoping I could shorten this to: <mule-ss:security-manager> <mule-ss:delegate-security-provider name="memory-dao" delegate-ref="authProivder"/> </mule-ss:security-manager> <ss:authentication-provider id="authProivder"> <ss:user-service> <ss:user name="ross" password="ross" authorities="ROLE_ADMIN" /> <ss:user name="anon" password="anon" authorities="ROLE_ANON" /> </ss:user-service> </ss:authentication-provider> But I still need to have DaoAuthenticationProvider around even if I use <custom-authentication-provider> it seems.
        Hide
        Luke Taylor added a comment - - edited

        Ok, so it seems that you have your own namespace which configures a Spring Secuiryt AuthenticationManager? Is that the case (I tried to read the docs, but it seems you have to register to do so ). If so, then my question would be why you don't just use the namespace AuthenticationManager we provide directly (or integrate it into whatever code you have behind that namespace). That way the usage patterns are the same in both scenarios - using Spring Security with or without mule.

        Show
        Luke Taylor added a comment - - edited Ok, so it seems that you have your own namespace which configures a Spring Secuiryt AuthenticationManager? Is that the case (I tried to read the docs, but it seems you have to register to do so ). If so, then my question would be why you don't just use the namespace AuthenticationManager we provide directly (or integrate it into whatever code you have behind that namespace). That way the usage patterns are the same in both scenarios - using Spring Security with or without mule.

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Dan Diephouse
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: