Dan Diephouse (Migrated from SEC-1053) said:
In Mule we allow people to wire in different authentication providers into the mule security manager. It seems with the 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.
Luke Taylor said:
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 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 tag.
Dan Diephouse said:
I wasn’t aware of that – I’ll look into it more. But, any reason I can’t do:
Seems like an unnecessary limitation.
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 . So there would not normally be any reason for referring to a namespace-defined AuthenticationProvider by Id.
OK, custom-authentication-provider isn’t really what I need. I stand by my assertion that should allow an ID. Take our configuration here for Acegi:
I was hoping I could shorten this to:
But I still need to have DaoAuthenticationProvider around even if I use it seems.
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.