OpenSAML should get initialized as part of container lifecycle #8772
Assignees
Labels
Milestone
Comments
jzheaux
added
type: enhancement
jzheaux
added a commit
to jzheaux/spring-security
that referenced
this issue
Jul 1, 2020
jzheaux
added a commit
to jzheaux/spring-security
that referenced
this issue
Jul 1, 2020
jzheaux
added a commit
to jzheaux/spring-security
that referenced
this issue
Jul 1, 2020
With the introduction of OpenSAML into the EnableWebSecurity annotation, it became necessary to have PowerMock-enabled tests ignore those classes. Issue spring-projectsgh-8772
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
OpenSAML gets initialized by Spring Security lazily via a package-private class
OpenSamlImplementation. This setup makes it tricky for an application to override the defaults that Spring Security specifies.For example, to use a different
ParserPoolconfiguration, one needs to ensure that they callXMLObjectProviderRegistrySupport.setParserPoolonly afterOpenSamlAuthenticationProviderorOpenSamlAuthenticationRequestFactoryis classloaded since those are the two classes that use an instance ofOpenSamlImplementation.It may be cleaner to initialize OpenSAML as part of the container lifecycle, for example as a
BeanFactoryPostProcessor. In this way, an application can register their ownBeanFactoryPostProcessorto override the behavior.At that point, the code can be removed in
OpenSamlImplementationthat initializes OpenSAML.The text was updated successfully, but these errors were encountered: